Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Wrong storage engine invoked during field_update_field()
Looks like a leftover from #443422: 'per field' storage engine. Before that, the 'field_storage_default' variable contained the storage backend used by all fields on the site. Each field has now itts own storage backend.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | field_update_field_non_default_storage-693054-3.patch | 958 bytes | yched |
| field_update_field_non_default_storage.patch | 886 bytes | yched |
Comments
Comment #2
catchHmm, #683028: field_storage_module needs to be field_storage_default in field.crud.inc changed field_storage_module to field_storage_default - on the assumption that this was the correct variable name for the storage module to be used if no other is specified - is that still right?
Comment #3
yched commentedre #2:
Yes, that was a two-fold bug:
- variable 'field_storage_module' is gone (was 'the one and only field storage backend used for all fields on the site', before #443422: 'per field' storage engine), we now have variable 'field_storage_default' ('the storage backend to use if none specified in field_create_field()'). #683028: field_storage_module needs to be field_storage_default in field.crud.inc switched that.
- but that was not the right fix :-). We should invoke the storage backend actually used by the field, not the default one.
Attached patch should fix the fails. Patch in OP used var $storage_type, which did not exist in the scope of field_update_field().
Comment #4
yched commented#3: field_update_field_non_default_storage-693054-3.patch queued for re-testing.
Comment #5
sunTrivial fix, looks good.
Comment #6
dries commentedCommitted to CVS HEAD. Thanks yched.