Problem/Motivation
When changing the schema provided by a field type (e.g. IntegerItem::schema()) we would have to migrate the storage for all instances of this field. Currently, we do not handle this situation.
We do track the schema that has been previously installed, but only by keeping track of old definitions + generating the old schema from them. But given the new code, the old schema will be generated differently as well.
Proposed resolution
Schema changes to a field type's schema were not officially supported in d7 either, but modules like entity reference shipped with custom updates taking care of it manually. So we need to
a) decide whether we want to officially support this and
b) find a good solution to the problem if we want to.
Comments
Comment #1
fagoTested it with #2337927: SqlContentEntityStorage::onFieldStorageDefinition(Create|Update|Delete)() is broken for base fields - changes to a field type's schema get detected right now as we store the serialized, last installed field definition which contains it's schema in the schema property. Later on it is retrieved from the populated schema property and thus schema changes are detectet.
That's good functionality, but it's more a coincidence that this is detected right now.
Comment #2
effulgentsia CreditAttribution: effulgentsia commentedFixed in #2337927-78: SqlContentEntityStorage::onFieldStorageDefinition(Create|Update|Delete)() is broken for base fields
Comment #3
yched CreditAttribution: yched commentedDidn't look at how this got fixed, but yeah, field schema being persisted on serialize was not intended originally.
Comment #4
fagoI think this is not fully fixed. Correct me if I'm wrong - but afaik we do only store the schema of shared tables now, so if a field is used in a dedicated table no update / migrate notification will appear?
Comment #5
effulgentsia CreditAttribution: effulgentsia commentedNope. SqlContentEntityStorageSchema::(create|update)DedicatedTableSchema() call saveFieldSchemaData(). But I think we're lacking test coverage for dedicated table (which means it might not be working), since the test coverage for shared table isn't via changing the field type, but via a change in EntityTestStorageSchema::getSharedTableFieldSchema(). Probably adding test coverage for a change in the field type itself, for both shared and dedicated, would be good.
Comment #6
BerdirIs this the same as this very old issue: #937442: Field type modules cannot maintain their field schema (field type schema change C(R)UD is needed)?
Comment #7
plach