I think we should make a cache_field_$entity table for each fieldable entity - i.e. cache_field_node, cache_field_user etc. This means table size (and hence overhead, key sizes etc.) will be a lot smaller, you'd be able to set up seperate cache bins in memcache per entity - good for when you have millions of records , and also backends like memcache which don't handle wildcard cache clearing very well. It also means we can use object id as the cache key, which should also make lookups a tiny bit faster than using composite strings like field:$obj_type:$id

Couple of very small kittens - hook_modules_installed() isn't called in install.inc, and hook_modules_uninstalled() is currently called after a module and all it's tables have been removed - not very useful if you need to check things like hook_fieldable_info() for the module being uninstalled.

Attached patch does a lot of the work - but things like simpletest are broken due to weird issues with which modules are actually loaded / installed during install. So marking postponed - I'm sure there's an issue somewhere but can't see it right now.

CommentFileSizeAuthor
cache_field.patch17.82 KBcatch

Comments

andypost’s picture

+1 for idea, suppose it should be configurable, wanna back latter to help.

andypost’s picture

Is this material still D7 related? Entity Cache live in contrib... as I know

yched’s picture

In principle I have no objections to this, but tracking the dynamic creation of the cache tables as entity types are enabled / disabled adds some logic and possible edge cases.

Hasn't cache_get_multiple() been extensively debated somewhere else ? (I might be wrong)

Also, this just leaves the 'field_info_fields' and 'field_info_types' entries in the 'cache_field' table, is it still worth a separate table ?

damien tournoud’s picture

Status: Postponed » Closed (won't fix)

I'm going ahead and marking this as won't fix.

It's pretty easy in Drupal 7 to implement a non-hackish "cache router", simply by implementing DrupalCacheInterface and calling the correct back-end cache. Sites that will need it can easily implement such splitting logic;