Problem/Motivation

#2666808: Add a revisionable entity base class and log interface introduced three revision metadata fields, which are named "revision_created, revision_user, revision_log_message". However the core still assumes at some places that they are called "revision_timestamp, revision_uid, revision_log". That is the case where the node entity and the block entity use the previous nomenclature. But unfortunately this is not the only place.. There is one another really important place and it is in SqlContentEntityStorage::getTableMapping where the only the old nomenclature is used to put these revision metadata fields in the "entity_type_id_revision" table. #2666808: Add a revisionable entity base class and log interface did not extend the list with the new revision metadata fields and what now happens is that if you use the new RevisionLogEntityTrait your revision metadata fields will not be put like they should in the "entity_type_id_revision" table, but they will be put in the field table.

Proposed resolution

Extend the list in SqlContentEntityStorage::getTableMapping with the new three revision metadata fields.

Remaining tasks

Discuss if it should be added in 8.1.x or in 8.2.x and if we need an update mechanism...

User interface changes

none.

API changes

The revision metadata fields from the RevisionLogEntityTrait now will be put in the "entity_type_id_revision" table instead in the field table.

Data model changes

none.

CommentFileSizeAuthor
#2 2732699-2.patch1.03 KBhchonov

Comments

hchonov created an issue. See original summary.

hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented
StatusFileSize
new 2732699-2.patch1.03 KB
hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented
Status: Active » Needs review
dawehner’s picture

dawehner
Primary language German
commented

Looks fair, its a bit sad that we don't automatically detect those fields but rather hardcode it.

      elseif ($revisionable && !$translatable) {
        // The revisionable layout stores all the base field values in the base
        // table, except for revision metadata fields. Revisionable fields
        // denormalized in the base table but also stored in the revision table
        // together with the entity ID and the revision ID as identifiers.
        $table_mapping->setFieldNames($this->baseTable, array_diff($all_fields, $revision_metadata_fields));
        $revision_key_fields = array($this->idKey, $this->revisionKey);
        $table_mapping->setFieldNames($this->revisionTable, array_merge($revision_key_fields, $revisionable_fields));
      }
      elseif (!$revisionable && $translatable) {

Does this changes the table scheme aka. we need some form of update path?

hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented

Yes, we'll need an update path as those revision metadata fields would now be in the field table for entities using the RevisionLogEntityTrait and they should be moved to the entity_type_id_revision table.

hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented
Status: Needs review » Closed (duplicate)
Related issues: +#2248983: Define the revision metadata base fields in the entity annotation in order for the storage to create them only in the revision table

Closing as the update path should be implemented in #2248983: Define the revision metadata base fields in the entity annotation in order for the storage to create them only in the revision table.