The default table mapping and the SQL storage do not agree on whether non-revisionable bundle fields should get a revision table

Problem/Motivation

Currently when you have a revisionable entity type with a non-revisionable field storage definition requiring a dedicated table, the (default) table mapping returns no dedicated revision table, while the storage and storage schema handlers expect the revision table to be there and try to read from/write to it.

This is bad, because the more we start relying on the table mapping to write schema-agnostic code, the more this discrepancy will bite us. Here's a prime example: #3056539: Updating an entity type from non-revisionable to revisionable fails if it has non-revisionable fields stored in dedicated tables → .

Proposed resolution

Use the same logic across the table mapping and the SQL storage/schema. Since reconciling the two behaviors is a BC break in either direction, we will need a BC layer and some form of deprecation.

We need to figure out whether we want the table mapping to behave as the SQL storage/schema or viceversa. Given that it’s perfectly legal to have a non-revisionable field on a revisionable entity type and that in such case there is absolutely no point in having a revision table, since it would be a straight copy of the data table, it's probably more correct to extend the table mapping logic to the SQL schema, however this is likely to require a more complex BC layer, as people might be relying on the existence of revision tables. In this case we'd likely be deprecating the existence of revision field tables for non-revisionable fields on revisionable entity types without actually dropping them.

Remaining tasks

• Decide how to reconcile the two behaviors
• Write a patch
• Reviews

User interface changes

None

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD