November 17, 2014

Drupal has built-in revisioning functionality for entities. When updating a node you may create a new revision to have some history of node changes and even revert to older or newer revisions so you may not worry about breaking your content because of saving wrong changes. There are a lot of contrib modules which extend revisioning functionality and provide new depending on it: for example it’s possible to force creation of new revision on each node edit and have moderation functionality so newer revisions will go live only after review.


To provide revisioning functionality for any entity type default field storage (Field SQL storage) which is used in most cases has built-in support for it as well. In the database you might notice tables which are usually called field_data_{field name} and field_revision_{field name} - the first one stores field data for current revision, the second one stores field data for all revisions of the entity including current revision. In case you do not use revisioning (even if used entity does not support revisioning at all!) field_revision_{field name} still stores current revision data which is the same as stored in the field_data_{field name}. For fieldable entities (for example nodes) most of data in size meaning is usually stored in fields and as result about a half of the data’s size takes revisions data which is just a duplication of current revision data (stored in field_data_{field name}) in case revisioning is not used!


Field SQL norevisions module makes it possible to select entity types and bundles for which you will not use revisions, and for selected fields revisions data (field_revision_{field name} table) will not be saved at all. First of all it saves database space. Furthermore it decreases number of SQL queries needed to save an entity to a database and as result increases performance when saving. So if you do not use revisioning (I’m sure there are entity types and/or bundles for which you will not use it) and have some problems with database size or frequently save (insert/update) fieldable entities to a database this module may be helpful for you.

Recommended branch of the module for use is 7.x-2.x. 7.x-1.x provided alternative storage backend for fields which is not 100% compatible with default storage, has no options to choose particular entity types / bundles, and also has some issues with some modules (for example Views so you have to patch it first) because they depend on default storage in some places. 7.x-2.x just alters default field storage and overrides its behavior just in a few places so you get much more compatibility with other modules.


Was this article helpful? Click to rate: 
Average: 4.8 (4 votes)

You may also like

Preface Drupal 8 has been released more than one year ago, but Drupal...
Some people think that SEO is a set of configuration options to...