I see the CCK and Views patch files (fixes serialized data already handled by memcache) - but no mention that they should be applied. What happens if they aren't.

We have a large site now that is using memcache with Drupal 5.7 and we haven't done these patches - but things still seem to be working.

Also, since our devel boxes (PC's) don't have memcache installed; but we use same patched core code base for development we simply "disable" memcache on our locals by not adding the $conf settings to swap out cache.inc. This seems to work ok; but if we do cck/views patches will these modules now not be broken without memcache - i.e. should the patch have an "if" of some sort wrapped around them (likely if the $conf var exists)?

Comments

robertdouglass’s picture

the fundamental way that caching is done in D5 is changed by the main memcache patch. Any non-core modules that do caching (like CCK and Views) should patch to be consistent. You are probably getting broken CCK and Views caching and just don't know. I recommend applying the patches. This is true whether or not you are actually running a memcache instance. Btw. it would be better if you just keep the memcache.inc (or rather memcache.db.inc) in the $conf because then you're running the actual code on devel that you're running in production. If no memcache is available it just fails gracefully (if not it's a bug)

robertdouglass’s picture

Status: Active » Fixed
liquidcms’s picture

Status: Fixed » Postponed (maintainer needs more info)

hmm.. don't think so

if no memcache installed on Apache and the $conf value is NOT commented out you get this error:

Fatal error: Class 'Memcache' not found in C:\Inetpub\websites\CAPSA\gcapsa\sites\all\modules\memcache\dmemcache.inc on line 162

as you have already stated in another issue posting.

crea’s picture

>the fundamental way that caching is done in D5 is changed by the main memcache patch. Any non-core modules that do caching (like CCK and Views) should patch to be >consistent. You are probably getting broken CCK and Views caching and just don't know.

Do you mean modules that still use serialize and deserialize by themselves dont benefit from cache if memcache+patch is used ?
Does it imply we should patch sources of every module thats using serialize each time there is new version ? Seems to be lot of work....I guess maintainers of modules won't be very happy to support 2 scenarios - with and without drupal serialization patch :)

Just a side question, Would it be possible to patch cache system to make transparent change for D5 so module weren't even know caching changed ?

firebus’s picture

you can patch source on each upgrade, or you can use a version control system to keep a separate vendor branch and merge in core changes when you upgrade.

it might be possible to patch cache as you describe - rather than patching core and contrib modules to remove the serialize calls, you could unserialize stuff in memcache.inc before sending it to memcache. i'm not sure if it's easy to tell what is serialized in cache.inc.

however, serialize/unserialize can be slow operations, especially for large objects, so you'd losing performance at the price of keeping the code cleaner.

memcache improves performance by taking load off the database, so adding some load to the web server to compensate might be a decent trade off

treksler’s picture

Hey,

never used memcached but want to give it a try
is patching required for drupal six versions of modules as well?

nnn’s picture

Please correct me if I am wrong here. If you use memcache.inc, then no need to patch anything. Only when you use memcache.db.inc you should patch your code.

Patching the core for memcache is not bad, since only 4 files are affected. But patching the contributed modules seems too much to do. In one of our sites, we have blockcache, calendar, cck, views, imagecache, update_status, etc. Total 18 files to be patched.

robertdouglass’s picture

Status: Postponed (maintainer needs more info) » Fixed

@nnn I think you're right about only having to patch contrib modules if using the memcache.db.inc. Good call.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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