Step to replicate the problem.

D7.10
views 3.0
ctools 1.0-rc1
search_api 1.0
search_api_solr 1.0-rc1

after i create a solr views (only with typology views) and when i add display

Notice: unserialize(): Error at offset 11253 of 11256 bytes in ctools_object_cache_get() (linea 41 di /home/dev/workspace/mysite/sites/all/modules/contrib/ctools/includes/object-cache.inc).

and then "access denied"

this issiue is also here http://drupal.org/node/1370724
The problem is only with postgres db, with mysql is working normally

Files: 
CommentFileSizeAuthor
#9 ctools-fix-postgresql-cache-error-with-data-column-typecast-1377634-09.patch1.69 KBthekevinday
PASSED: [[SimpleTest]]: [MySQL] 51 pass(es).
[ View ]
#8 ctools-fix-postgresql-cache-error-with-data-column-typecast-1377634-08.patch1.54 KBbendiy
PASSED: [[SimpleTest]]: [MySQL] 51 pass(es).
[ View ]
#1 solr1.png103.41 KBulyx451
#1 solr2.png85.63 KBulyx451

Comments

StatusFileSize
new85.63 KB
new103.41 KB

Some screenshot

solrerror

I've tryed and I notice that when ctools add to database the cache, it serializes the $cache.
Serializing the $cache variable I notice that the string as many "\", backslashes that broke the query insert, so in the db, when the function ctools_object_cache_get, the serialize of the result of the query fails and I obtain the error in the screenshot.

The abstraction layer for postgres does not add any "escaping" function to the query..
I've tryed to base64_encode the data before the insert query, and obviously base64_decode after the ctools_object_cache_get function, and everything seems ok, but I think it isn't the right way.

So now I've, in my object-cache.inc:

Line 40-42:

<?php
if ($data) {
     
$cache[$key] = unserialize(base_64_decode($data->data));
    }
?>

And line 67-75:
<?php
db_insert
('ctools_object_cache')
    ->
fields(array(
     
'sid' => session_id(),
     
'obj' => $obj,
     
'name' => $name,
     
'data' => base64_encode(serialize($cache)),
     
'updated' => REQUEST_TIME,
    ))
    ->
execute();
?>

Any other solution?

Sergio

I've catched same error in my PostgreSQL

I change Db schema for fix

ALTER TABLE drupal_ctools_object_cache  DROP COLUMN data;
ALTER TABLE drupal_ctools_object_cache  ADD COLUMN data bytea;

before:

t1=> \d  drupal_ctools_object_cache
       Table "public.drupal_ctools_object_cache"
Column  |          Type          |     Modifiers
---------+------------------------+--------------------
sid     | character varying(64)  | not null
name    | character varying(128) | not null
obj     | character varying(32)  | not null
updated | bigint                 | not null default 0
data    | text                   |

after:

t1=> \d  drupal_ctools_object_cache
       Table "public.drupal_ctools_object_cache"
Column  |          Type          |     Modifiers
---------+------------------------+--------------------
sid     | character varying(64)  | not null
name    | character varying(128) | not null
obj     | character varying(32)  | not null
updated | bigint                 | not null default 0
data    | bytea        

patch

--- a/ctools/ctools.install 2012-01-15 15:41:53.000000000 +0400
+++ b/ctools/ctools.install 2012-01-15 15:43:24.000000000 +0400
@@ -195,3 +195,12 @@
}
+
+function ctools_update_6008() {
+  db_change_field('ctools_object_cache', 'data', 'data', array(
+        'type' => 'blob',
+        'description' => 'Serialized data being stored.',
+        'serialize' => TRUE,
+  ));
+}

Ok thanks a lot.
Sorry, but I'm not an expert of drupal.org and patches ;)
I've to submit this patch in the -dev release?

Thanks,
Sergej

This is the same problem as #865142: Make ctools_object_cache.data DB column blob for storing arbitrary bytes. and #690746: Text column type doesn't reliably hold serialized variables, the latter of which was opened a year ago (and hasn't been fixed, just marked duplicate of the former). I really wish this was fixed properly because without a proper fix, using Drupal under Postgres (and possibly other DBMSes) is not feasible. :(

Version:7.x-1.0-rc1» 7.x-1.x-dev
Status:Active» Reviewed & tested by the community

#3 fixed this for me on PostgreSQL 9.1.

I got a similar error when trying to add content to a Pane in Panels. I added a ECK entity in the Panel "Contexts". When I go to "Content" and add a field from that ECK entity to a pane, I get the error when I click "Update" or "Update and Save".

It's working now after #3. Thanks!

Status:Reviewed & tested by the community» Active

Can't be RTBC, there's no patch.

Status:Active» Needs review
StatusFileSize
new1.54 KB
PASSED: [[SimpleTest]]: [MySQL] 51 pass(es).
[ View ]

Patch attached.

I put the change in ctools_schema_2() and ctools_update_6008(). Not sure if one is better than the other.

StatusFileSize
new1.69 KB
PASSED: [[SimpleTest]]: [MySQL] 51 pass(es).
[ View ]

Does not work:

Failed: PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type bytea: ALTER TABLE {ctools_object_cache} ALTER "data" TYPE bytea USING "data"::bytea; Array ( ) in db_change_field() (line 2985 of /var/www/drupal/advising/includes/database/database.inc).

It turns out if certain text information is inside of data, then the alter will not work.
The solution is to clear the tools object cache immediately before doing the alter.
After making this change I managed to apply the update and confirm that the changes work.

Also, I added a description to the update.

Status:Needs review» Fixed

Committed and pushed, but I had to adjust it to a 'big' blog, so that it's a longblob in mysql. Otherwise the data size is way too small for anything.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.