IntColumnHandler doesn't handle revision tables yet add tests find the issues.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | target_id_int_column-2772611-15.patch | 9.8 KB | jibran |
IntColumnHandler doesn't handle revision tables yet add tests find the issues.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | target_id_int_column-2772611-15.patch | 9.8 KB | jibran |
Comments
Comment #2
jibranHere is the basic test for start. It passes on both 8.x-1.x and 8.x-2.x.
Comment #3
jibranComment #6
jibranFixed the stupid copy paste error.
Comment #7
jibranMinor observation.
Field Revision table is always a dedicated table if an entity is revisionable.
column name is same across the tables.
Comment #8
jibranAdded #2773099: Add tests for base fields of revisonable entity as a follow up. After that we can work on upgrade path test for base fields of revisonable entity.
Comment #9
jibran$field_storage_definitioncan be NULL so changed the variable.Comment #11
jibranThese fails are in the HEAD because of #2775539: DerUpdateTest is failing after 2755525 and #2755525: Invoke field methods first on the current entity translation.
Comment #12
jibranCurrent patch is only fixing the bug: "target_id_int column doesn't exist for entity revision field tables."
Comment #13
jibranfield revision table only exist if both entity and field storage are revisionable.
Comment #14
chx commentedyes, we only need to deal with some revision table if both definitions are revisionable. However, the field will only live in a dedicated table if its cardinality is not 1. If its cardinality is 1 then it might live in the shared revision data table (if the entity is translatable) or the just revision table (if the entity is not translatable) but it's enough to just rely on the table name being non-empty as SqlContentEntityStorageSchema::getEntitySchemaTables does. So:
Comment #15
jibranThanks for the explanation. Here is the new patch
Comment #16
chx commentedSo... I have read the patch and of course it looks great! Then I began wondering, does the system even put the revision data into the keyvalue? I mean, it could skip it, the revision and the base column schema are obviously the same.
So I opened the database and select * from key_value where name like 'node.field_schema_data.changed'; and yes, node_field_revision is there. While theoretically we could just use this data in the update handler, we couldn't do so in FieldStorageSubscriber because as are painfully aware it might happen that one gets called before the database actually contains the field columns.
Comment #18
jibranThanks! committed and pushed to 8.x-2.x
Comment #19
jibranJust for the record the upgrade path test for this change is still pending.