field_update_field() calls the wrong field storage backend [#693054]

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
#3
	field_update_field_non_default_storage.patch	886 bytes	yched

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

23 January 2010 at 01:00

Status:

Needs review

» Needs work

The last submitted patch, field_update_field_non_default_storage.patch, failed testing.

Comment #2

catch

he/him

English

CreditAttribution: catch commented 23 January 2010 at 06:02

Hmm, #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 CreditAttribution: yched commented 30 January 2010 at 03:44

Status:

Needs work

» Needs review

File	Size
field_update_field_non_default_storage-693054-3.patch	958 bytes

re #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().