Encountered this through entityreference.

A feature was made with an entityreference field, and its schema was fully exported.

The module was updated, and entityreference_update_7001() was run.

The target_type column was dropped, but running features update didn't change the schema, and running features revert attempted to add target_type as an index, causing PDO fatals.

The target_type index lines in the field schema had to be manually removed.

CommentFileSizeAuthor
#1 achievecommunity_gateway_page.zip8.45 KBrussc

Comments

russc’s picture

StatusFileSize
new8.45 KB

I think I have the same issue. I created the attached feature ZIP from a customer website, and installed it on a clean 7.12 site with minimum other modules - entity api, entityreference, ctools, views, panels.

When enabling the module I get this error:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1072 Key column 'field_ref1_target_type' doesn't exist in table: CREATE TABLE {field_data_field_ref1} ( `entity_type` VARCHAR(128) NOT NULL DEFAULT '' COMMENT 'The entity type this data is attached to', `bundle` VARCHAR(128) NOT NULL DEFAULT '' COMMENT 'The field instance bundle to which this row belongs, used when deleting a field instance', `deleted` TINYINT NOT NULL DEFAULT 0 COMMENT 'A boolean indicating whether this data item has been deleted', `entity_id` INT unsigned NOT NULL COMMENT 'The entity id this data is attached to', `revision_id` INT unsigned NULL DEFAULT NULL COMMENT 'The entity revision id this data is attached to, or NULL if the entity type is not versioned', `language` VARCHAR(32) NOT NULL DEFAULT '' COMMENT 'The language for this data item.', `delta` INT unsigned NOT NULL COMMENT 'The sequence number for this data item, used for multi-value fields', `field_ref1_target_id` INT unsigned NULL DEFAULT NULL COMMENT 'The id of the target entity', PRIMARY KEY (`entity_type`, `entity_id`, `deleted`, `delta`, `language`), INDEX `entity_type` (`entity_type`), INDEX `bundle` (`bundle`), INDEX `deleted` (`deleted`), INDEX `entity_id` (`entity_id`), INDEX `revision_id` (`revision_id`), INDEX `language` (`language`), INDEX `field_ref1_target_entity` (`field_ref1_target_type`, `field_ref1_target_id`), INDEX `field_ref1_target_id` (`field_ref1_target_id`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'Data storage for field 15 (field_ref1)'; Array ( ) in db_create_table() (line 2688 of C:\Drupal Sites\sites\drupal-7.12\includes\database\database.inc).

tim.plunkett’s picture

Priority: Normal » Major

Yes, that's exactly the error.

elshae’s picture

Subscribe I'm experiencing this exporting any content with entityreference fields...

However, thanks to timplunkett who helped me through this in IRC, I found a fix for now:

In my case I had an event content type which had an entity reference field of speaker content type. I had made a feature for each and exported my feature made modules to my new site. Everything was fine, except I kept getting the SQL error mentioned above and I could not get the entity reference field to be created in the event content type no matter what. The problem is that target_type was a column in the older versions of entity reference which has been removed but wasn't removed from the features code. When features creates a module for you, it still references this 'target_type'.

  1. Go to your features created module in sites/all/modules/
  2. Go to the file .features.field.inc
  3. Do a find on 'target_type' without the quotes you should see something like :
  4. indexes' => array(
            'target_entity' => array(
              /*0 => 'target_type',*/
              0 => 'target_id',
            ),
          ),
          'module' => 'entityreference',
          'settings' => array(
            'handler' => 'base',
            'handler_settings' => array(
              'sort' => array(
                'direction' => 'ASC',
                'field' => 'body:value',
                'property' => 'title',
                'type' => 'property',
              ),
              'target_bundles' => array(
                'speaker' => 'speaker',
              ),
            ),
            'handler_submit' => 'Change handler',
            'profile2_private' => FALSE,
            /*'target_type' => 'node',*/

Comment out as you see I have done above. 1 => 'target_id' should become 0 => 'target_id'

Run update.php, your entity reference field should be there and the errors should be gone as well.

mpotter’s picture

Status: Active » Closed (works as designed)
emjayess’s picture

"works as designed"... really?

tim.plunkett’s picture

Status: Closed (works as designed) » Active

Whoa, I missed that...

mpotter’s picture

Status: Active » Postponed (maintainer needs more info)

Sorry, didn't mean to mark this one closed...too many issues in one day ;)

In any case, I don't see anything I can do to help with this in Features itself. Features is just exporting the $field data array that comes from field_info_field (in 'field_config') and from field_info_instance (in 'field_instance'). You didn't include the full export above so I don't know if you are commenting out something from field_config or field_instance or from somewhere else. But it sounds like the entityreference module is adding a key/value to the field data that is causing this problem.

If somebody can point me to something Features itself is doing to cause this, let me know and I'll look into it again.

hefox’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Category: Bug report » Support request
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Fixed

I think what needed to happen was

1) Disable rebuild during cache clear (possible in 2.x)
2) update feature after field was updated.

I sounds like features rebuilt the field to re-add in the removed key.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.