1

Even with revisions turned off for a given content type, the field_revision_* tables for the fields each contain a single record that matches the corresponding record in the corresponding field_data_* table.

I've always been aware of this, and previously, I've never had a reason to question it. However, now I am dealing with an extremely large database, and almost 50% of the database size is made up of this duplicated data in the revisions tables.

Why do we duplicate all the field data in the revision tables when revisions are disabled for a content type?

Improve this question
2
  • There is a module that will remove this data, Field SQL norevisions. This does irreversible things to your database, so beware. It it written by alexpott, so I think it is safe to assume he knows what he is doing.
    – mpdonadio ♦
    Jul 12, 2014 at 23:14
  • I actually discovered that module yesterday. The 7.x-2.x version was built by the team from Highwire Press who are dealing with similar big data issues. This seems like the solution I will pursue.
    – BrianV
    Jul 14, 2014 at 13:47

1 Answer 1

Reset to default
0

That's a great question - I wonder if it's any different in D8.

The field_data tables, and node table also track the "current vid" which is the current revision id, I guess they felt there had to be at least one. But it does seem like there should be another way to do this. Maybe they could just store a 0 or something as a flag in the field_data tables current_vid column to indicate there's not a revision.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.