Situation (numbers reflect points in time of a site):

1. Live site is in state 'A' : features are in use, providing various fields. An update hook is written that does something, including clearing caches, probably by using drupal_flush_all_caches(). This update hook is not executed yet (for example, because all the development described here is released to live in one go, so there are multiple update hooks to run)

2. During later development, a new field is added to a feature, which uses a new field type module that wasn't available at point (1).

3. Another update hook is now needed to enable the new module.

4. All this is released to live and update hooks are run. The update hook from point (1) clears caches - and in doing so, fails. This is because on clearing caches, the feature is rebuilt and the new field is detected. But because the module that supplies its field type is not enabled yet, it is not recognised, and a FieldException is thrown during field_create_field(). The update system catches this and aborts the updates. Updates cannot proceed, because the module is enabled in a later update hook.

Clearing caches in any other way also causes a fatal exception, but it is a particular problem in the update system because updates are aborted, when it is a later update hook that would fix the problem by turning on the new module.

When reverting features, the feature's module dependencies are checked (I think), so this isn't a problem, but on simply rebuilding, there may be new dependencies that aren't available so this happens. Something should be done - some ideas for discussion:
1) Enable dependencies even on rebuilding a feature (though this would happen on clearing caches, which may be a bit drastic)
2) Report the problem so the user can enable the new module(s).
3) Check that any fields to be created can be created first - then either just don't create them (they'll get created on a later rebuild when the new module is available), or report the situation to the user/admin.

Files: 

Comments

Priority:Normal» Major

We had this same problem just now, having added both new field types to an existing feature of type 'email' and 'link'.

Eventually we had to enable both email and link modules at the same time, before doing anything else to our staging server. Enabling either individually would cause the feature to break the site, so it seems enabling modules also causes this feature rebuild process.

Priority:Major» Normal

Oops

have the same issue.

drush @site.local cc all
WD php: DatabaseSchemaObjectExistsException: Table field_xxxxx already exists. in DatabaseSchema->createTable() (line 657 of  /xxxxxxxxxxxxxxxx/docroot/includes/database/schema.inc).

I got the same error when clearing the cache on a D7 installation and only could get the site working again after disabling Features using Drush: #1551132: DatabaseSchemaObjectExistsException: Table already exists. in DatabaseSchema

DatabaseSchemaObjectExistsException:
Table <em class="placeholder">field_data_field_body</em> already exists. in DatabaseSchema->createTable()
(line 657 of ...\includes\database\schema.inc).

I also cannot access admin/structure/features and /admin/modules.

Some more probably related issues.

Version:7.x-1.x-dev» 7.x-2.0-beta1
StatusFileSize
new62.68 KB

I am having the same issue on D7 with 2.0-beta1.

Status:Active» Closed (duplicate)

Solution is here (needs repatching for 2.x): #1664160: Catch field exception when rebuilding

edit: deleted / wrong thread