Field SQL norevisions provides a field storage backend that prevents entity revisions from being saved to the MySQL storage backend.

The purpose of the module is to reduce the amount duplicated data that is saved on large Drupal sites that do not use revisions. It has the additional performance benefit of halving the number of queries during creating entities with fields.

Field SQL norevisions module will keep empty revision tables in the database. Do not delete those tables, since it will break your site. Keeping them in the database enables Field SQL norevisions module to work properly with Views, Taxonomy and other modules that expect revision tables to exist.

How production ready is this module?

From pwaterz:

In my current job we have built a platform for scholarly journals via Drupal. We currently have 200+ sites running on this platform. Our platform makes use of 200+ contrib modules. Our major cluster consists of 20+ web heads, 12 memcache servers, and 15 mysql servers. We run this module on every single one of those sites and have been doing so for 2 year+ now and have seen 0 issues. I have a lot of confidence that this is production ready.

7.x.2.x

- Ability to turn revision on and off per entity/bundle
- Ability to bulk delete revisions currently in your database

You can not upgrade from 7.x-1.x to 7.x-2.x, it will break your site.

This new 7.x-2.x release changes the core logic of how Field SQL norevisions prevents revisions from being stored. In the 7.x-1.x release revisions tables were not created at all. This was problematic because it created an all or none approach. The new version of this module allows you to turn revisions on and off per entity/bundle. Again once the revisions are deleted you can not get them back.

7.x-1.x

The module includes a small patch for views in order to work with fields create using the new backend. This patch is no longer required for 7.x-2.x release.

Project information

Releases