Posted by jlyon on June 27, 2011 at 10:24pm
18 followers
Jump to:
| Project: | Features |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I am trying to install a feature on an existing site with that already has some of the same field names (field_image for example), and I get the following error:
FieldException: Cannot change an existing field's type. in field_update_field() (line 230 of /var/aegir/platforms/dcpl-drupal7/modules/field/field.crud.inc).This is related to #1058902: Error when enabling Debut Article, where they recommended:
This bug can be fixed following an approach used in media_gallery.install, which detects existing fields and throws a hook_requirements() error if there's an existing field with the same name but a different type. Arguably this should go in features, but a workaround in debut_article and other debut features meanwhile is important.
Comments
#1
subscribe
#2
I'm experiencing the same issue, and I wonder why this shouldn't be allowed. I'm trying to update a file field to an image field using Features. The change really is minimal, but as the comment in field.crud.inc says around line 230: "// Some updates are always disallowed." Why exactly is Drupal core specifically disallowing us from doing this?
Should we move this issue to Drupal core?
#3
Core disables changing an existing field's type because changing the field type possibly means changing the data schema ('columns'). Changing field type is considered a data migration topic, and left for contrib to handle - it was out of scope of the Field API D7, as it was out of scope of CCK D6.
In terms of Features, though, I guess Features could handle deletion / recreation of a new field with the same name - that means the loss of field values, though.
#4
I don't think deletion/recreation is the way to go (and I don't think loss of field values is acceptable). My use-case was a move from filefield to imagefield which isn't so drastic.
Given this information, I'm inclined to mark this as "Won't fix".
#5
We ran into this problem when changing a field type from text to text_long, which took down our QA server until I figured out what happened. Would be nice if features gave a warning about this before drush fu is run (ie. danger will robinson, you have changed a field type, are you sure you want to proceed?).
#6
Hm, my guess is ideal here would be for features to prevent enabling of the module, and for another contrib module to handle converting the fields (so then the feature could be enabled). Or tell user that that field needs to be deleted.
#7
Same problem here. Is the only option to completely wipe the database and reinstall from scratch? Or are there some shortcuts such as deleting certain tables/rows from the database that would provide a temporary workaround?
#8
There's possibly a related topic in #1664160: Catch field exception when rebuilding (esp. in regards to DB column change). The stopgap was for Features to catch the
FieldUpdateExceptionand log the error. Of course, the problem is magnified in Drush.#9
This also happens when names of fields clash. #1473244: FieldException: Cannot change an existing field's type. in field_update_field()
#10
I got this error and I went through and deleted all the content types (via the Drupal UI) and then the error went away (all content types were in a Feature so I didn't lose anything).