Existing index issue with revision_id index

I also have this error. The patch is fixed.

My fields were already in features and when the update broke the site with this error I had to run this script to fix it:

$result = db_query("SELECT id, data from field_config where type = 'field_collection'");
foreach ($result as $field) {
  $data = unserialize($field->data);
  $data['indexes'] = array('revision_id' => array('revision_id'));
  $data = serialize($data);
db_query("update field_config set data = :data where id = :id", array(':data' => $data, ':id'=> $field->id));
}

Presumably this situation would not have occurred with the patch from 5 applied before I ran the update.

Thanks everyone for the patches and tips!

I can confirm this is a bug, and that patch in #5 prevents it. Also, the script in #7 is great for fixing it after the fact.

Attached is the same script in drush-script format. For anyone not familiar...

1. Make sure you have drush installed and in your path
2. Rename download file to fix-fields.drush and make sure it's executable (chmod +x ./fix-fields.drush)
3. Run the script: ./fix-fields.drush @default to fix your db (replace @default with your site alias, if necessary)

Just a humble thanks for #7 :-)

The patch in #5 is working fine for me as well.

Given that this could be broken for sites that already tried to upgrade, I wonder if the drush script from #8 should be integrated into an update hook as well?

Here's an example update hook one might use to fix this on their site:

/**
 * Fix field_collection field indexes.
 * 
 * This is due to a bug in a previous field_collection module update. The
 * drupal.org issue describing the bug: https://drupal.org/node/2141781 
 */
function example_update_7000() {
  $result = db_query("SELECT id, field_name, data
    FROM {field_config}
    WHERE type = 'field_collection'");

  foreach ($result as $field) {
    $data = unserialize($field->data);
    // If we already have the index on this field, continue to the next field.
    if (isset($data['indexes']['revision_id'])) {
      continue;
    }
    // Otherwise, add the revision_id index.
    $data['indexes']['revision_id'] = array('revision_id');
    // Re-serialize the data.
    $data = serialize($data);
    // And now update the field.
    $num_updated = db_update('field_config')
      ->fields(array('data' => $data))
      ->condition('id', $field->id)
      ->execute();
    // If for some reason the update failed, throw an exception.
    if ($num_updated != 1) {
      $t_args['@field'] = $field->field_name;
      throw new DrupalUpdateException(t('An error was detected when attempting to update field configuration for field @field.', $t_args));
    }
  }
}

I rolled a new patch combining segi's patch from #5 with q0rban's update function from #11. After applying this patch and running drush updb my problem seems to have been fixed.

Agreed.

I tested the patch in #12 and it removes the error message, but in my case something is not saved to the database correctly..I think.
I use the multiple value widget for a field collection field. The error appeared when I tried to save the field collection field settings.
After the patch, I can save it, but the multiple value widget settings are not applied to the field collection.
I uninstalled and reinstalled the multiple value widget module, but still the same. So I think something is still not working in this patch.

1. +++ b/field_collection.install
   @@ -269,15 +269,40 @@ function field_collection_update_7003() {
   +    field_update_field($field);
   

   What's that for? Should be commented as unclear.

2. +++ b/field_collection.install
   @@ -269,15 +269,40 @@ function field_collection_update_7003() {
   +  $result = db_query("SELECT id, field_name, data
   

   Should use field_read_fields as above?

is this patch any simplier?

this allowed me to run field_collection_update_7004(), after changing from dev to 1.0-beta7, where i had already ran this update.

remove extra argument from patch in #2141781-16: Existing index issue with revision_id index.

The patch in #12 appears to be working well for me.

Can't we just check before adding the index? For failed upgrades, the indexes may have been added already.

Hi,

After upgrading from Beta4 to Beta7 I have some issues, one of them was not being able to modify the field properties..

fix-fields.drush has allowed me to edit the field properties again which is great, but not resolved main problem of not being able to create new nodes with field collections..

Anyway.. Reason for this post is to say that the script doesn't work if you have a database table prefix so this had to be added to the two "field_config" references in the script..

The patch in #12 by @jstoller is what did it for me. I had a site that has been working on beta5 just fine for many, many months. But then when I wanted to update the field collection field, I got the error that an attempt to add the index failed due to it already being on the field. I thought it odd because I wasn't running update at the time, just updating a field.

Only the patch in #12 fixes my issue due to me having an existing install of beta5 versus trying to upgrade from a previous version. The code in field_collection_update_7005() was critical for me and this patch is the only one that has that.

I have tested the ability to make changes to the field collection field and all seems to be working fine. Thanks!

I applied #20 patch and it fixed the main issue but had to use the code mentioned in #7 to fix it
for existing fields after the upgrade
However it think that a new update should be included in the next release to automatically fix the issue, therefore the code mentioned in #7 can be included as update_7005

Here I am combining patches #12 and #20. It addresses the following scenarios outlined in the thread:

• Clean installations, where revision_id indexes will be added to the database and to the field_config table.
• Broken installations, where field_config rows for field_collection fields will be updated with the revision_id index.

Patch at #25 worked well for me.

The only difference between this patch and #25 is that I've moved the new update function to field_collection_update_7006(), since field_collection_update_7005() has already been committed to dev. I'm also bumping the priority, since I can't update my sites without a constant error until this patch gets in, and I can't deploy this patch myself, for fear that a different #7006 update function will be committed first.

I've tested this patch both by doing a fresh update, and by fixing an update that had already been performed using the existing dev release. Both cases worked perfectly, with no more errors.

Given #27 is just a minor re-roll and #25 was working for people, I'm marking this RTBC. Feel free to change it back if you think that is premature.

Patch in #27 worked fine for me. +1 for committing.

Works for me and needed this patch quite significantly.

Thanks all.

Patch #25 worked well for me.

Patch #25 worked well for me.

#25 did the trick. Thanks.

Hi

To work it out the https://www.drupal.org/node/2141781 with latest version of 7.x-1.0-beta11 for field_collection module. have updated the patch.