I have set up a sandbox project at http://drupal.org/node/1570130 which allows you to write separate cache keys to the database per domain. I would appreciate it if some of the domain access gurus could cast their eyes over it and let me know if I'm doing anything horribly wrong. Basically I'm creating a new cache backend which extends the DrupalDatabaseCache and prefixes the cache keys with the domain id. There is also a class there for memcache, but I haven't test that out yet. Anyway, I would appreciate any feedback you've got.
Comments
Comment #1
agentrickardYou normally don't need this for the {cache_page} table or the {cache} table. Say more about the use-case here.
Comment #2
mstrelan commentedEither cache_views or cache_views_data table is a problem if you use the time-based caching options in views. Also cache_field can be a problem on filtered text fields under certain configurations, for example with Pathologic set to rewrite to absolute URLs - it will cache the domain name of whichever domain was being viewed when the cache was generated.
There's two examples, likely to be more.
Comment #3
agentrickardDomain CTools may already provide this for Views. The {cache_field} bit makes some sense.
Comment #4
mstrelan commentedI had a quick look at this and it doesn't appear to help, the following from the project page confirms that.
The specific issue I'm dealing with for Views is a block view showing image thumbnails with different images per domain. The views style plugin is jcarousel (from the jcarousel module) and for one reason or another it can be very slow to load without setting time-based caching on the views results. It is the {cache_views_data} table that stores this cache and either needs to be prefixed per domain or have separate cache keys per domain. The domain_prefix module is not available for D7 and it is too messy trying to prefix the tables in settings.php.
The module provides an administration page to exclude certain cache bins from being separated. You are right that most tables probably don't need separating - you almost certainly don't want to separate {cache_update} and it is impossible to separate {cache_bootstrap}. I feel that {cache_field} and {cache_views_data} are good enough reasons to use this module.
Comment #5
alan d. commentedCurrently {cache} appears content free.
But to list some generic issues:
Enable a cached global token filter and use [site-name] and you have domain specific content if the rendered content is stored, {cache_filter} and ???.
We have entity specific titles per domain - same node, different titles. We were getting the titles cached as these are set during entity_load(). As a result, we can not trust anything per domain, so if it has content, we have to assume that somewhere there is domain specific info.
Metatags was caching the wrong HTML page domain titles, although we never tracked this down - a simple template preprocess HTML fixed that one though.
Another modification allows block domain titles, another potential issue.
Basically, it is a huge and complex collection of sites, and we simply do not trust any content that is stored. Thus if it is a content cache, we are looking at caching per domain. We would rather a bloated database than an unhappy client.
Comment #6
agentrickardMakes sense to me, thanks for the background.
Comment #7
damienmckennaSo is the problem that you can't change the cache tables per domain, or that you want a more generic solution that would work regardless of the caching backend (database, memcache, etc)?
Comment #8
mstrelan commented@DamienMcKenna - it would be equally suitable to prefix the cache tables in settings.php but I'm not sure how easy that is to do with DA, particularly automatically when adding / modifying domains.
Comment #9
damienmckennaAh, yes, it was Domain Prefix I was thinking for in D6 and was expecting it to exist for D7 too. Bummer.
Comment #10
mstrelan commentedI've just promoted Domain Cache as a full project.