I have a field type in which the schema can be edited by the user in the UI. They can add or remove columns to the field schema, which means there also may be indexes that existed in my hook_field_schema() at one point when the field is created, but later does not exist. The problem I'm experiencing is that when field_update_field() is called which should drop the old field table and re-create with the current schema, it loads the 'old' indexes from the field_read_field() stored in the database. This causes a database exception because field_sql_storage attempts to create an index on a table column that does not exist.
It seems that field_create/update_field() supports passing in additional indexes that are not defined in hook_field_schema(), which frankly seems like a very bad idea.
This will need to be verified if this also is present on Drupal 8.
Comment | File | Size | Author |
---|---|---|---|
#16 | 2311095-field-update-remove-index-test-only.patch | 3.94 KB | Dave Reid |
#6 | 2311095-field-update-remove-index-test-only.patch | 4.18 KB | Dave Reid |
#4 | 2311095-field-update-remove-index.patch | 6.17 KB | Dave Reid |
#1 | 2311095-field-update-remove-index.patch | 3.34 KB | Dave Reid |
Comments
Comment #1
Dave ReidPatch to confirm the failure.
Comment #3
Dave ReidExcellent, this demonstrates the problem exactly.
This is so confusing *why* we support allowing arbitrary indexes to be added to a field that aren't registered with the field's hook_field_schema(). Also it seems completely wrong that we don't separate it into a separate property in the field definition array like 'custom indexes'. It makes it *completely* impossible to determine which indexes are custom, and which indexes are from the field, and when an index should no longer stay around, which is the problem here.
Comment #4
Dave ReidWe just need to add a new 'custom indexes' property to the field array.
Comment #6
Dave ReidLooks like this might affect D8 as well. Try a test-only version first.
Comment #7
Dave ReidComment #9
Dave ReidThis blocks multifield from being ported to D8.
Comment #10
Dave ReidSo frustrated that both D7 and D8 store raw data from hook_field_schema() in the field definition instead of "custom things that override the schema in particular cases."
Comment #11
Dave ReidComment #12
catchThis has likely been fixed by #2555665: When index is added for content_translation_uid, the corresponding stored schema definition is not updated and related issues in the past six months which massively overhauled entity/field schema handling.
If it's still an issue it needs re-confirming.
Comment #14
Dave ReidStill an issue, test is failing.
Comment #16
Dave ReidRe-rolling the test to see if it fails.
Comment #18
catchSql-backed field schema updates that add columns fail
Comment #22
xjmIs #2532864: Sql-backed field schema updates that add columns fail a duplicate?
Comment #33
acbramley CreditAttribution: acbramley at PreviousNext commented7 years since the last comment, we'll definitely need to check if this issue still exists on 11.x, although given the length of time I'm sure all the code looks wildly different so may be hard to know.