Fields with no revisions

No time to read it now?

We will send a link to the article to your inbox

Read later

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 contributed modules which extend revisioning functionality and provide new depending on it: for example, it’s possible to force the 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 store 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 the 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 the 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 the 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.

Fields with no revisions 1

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.

You might also like

Website audit check-list

How to Conduct a Website Audit: A Beginner's Guide

A website audit is a necessary checkup that shows what is lacking in terms of content, SEO, design, and usability. We composed a short website audit checklist so that you can conduct the audit on your own and improve website performance.
how to seo a website

How to SEO a Drupal website

Learn how to optimize your Drupal website for search engines with this comprehensive guide. Discover the steps to configure meta tags, create clean URLs, optimize content, and improve site performance