This project is not covered by Drupal’s security advisory policy.

This integrates the revisioning module with entitycache.


There had been three problems:

- a) Entities loaded directly as revisions (even though the current revision is the live revision) and hence having no entity caching at all.
- b) Entities loaded as revisions, but that need the draft / latest revision.
- c) The whole cache was cleared by revisioning module by calling node_load($id, NULL, TRUE), which led to entity_load() clearing the whole persistent cache when any node was saved.


For a) the revision_id is simple ignored as the right one will be loaded anyway to improve cache hit ratio.

For b) the entity is loaded / stored from a special entity cache that is keyed by revision_id if and only if the entity is the latest revision.

Resetting the cache for an entity removes all stored revisions together with the entity itself.

For c) I discussed this with catch the maintainer of entitycache and while it makes sense to clear the static in-memory cache, it does not make sense to clear the persistent cache, so only the persistent cache for $id will be cleared in this case.

Also a watchdog warning was added to ensure that should something else clear the whole cache there is a warning in the logs.

These changes could go upstream to entitycache module itself one day as they are generally useful. They are needed here however as revisioning itself clears the whole cache.

Development sponsored by the Swiss Red Cross (

Project information

  • caution Minimally maintained
    Maintainers monitor issues, but fast responses are not guaranteed.
  • caution Maintenance fixes only
    Considered feature-complete by its maintainers.
  • Module categories: Performance and Scalability
  • chart icon57 downloads
  • shield alertThis project is not covered by the security advisory policy.
    Use at your own risk! It may have publicly disclosed vulnerabilities.