Duplicate entry '0' for key 'revision_id'

I am also facing same issue but after some debugging found that the issue with my own custom module I have, where I am trying to create terms of "type A" in backend( Programitically ) while creating new term of "Type B".

You can check if same is happening with you.

S.

The reason this error appears is because the contrib module : entity should be added as a dependency for the taxonomy_revision module otherwise the entity_ids cannot be found (basic).

added new patch file, cause the old one was empty and the uploader had issues with updating the issue.

I faced the same issue. When trying to add new term in node edit form, getting 500 500 Internal Server Error and this error message:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0' for key 'revision_id': INSERT INTO {taxonomy_term_data} (vid, name) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => 6 [:db_insert_placeholder_1] => The name of the new term ) in drupal_write_record() (line 7202 of includes/common.inc).

When I looked in {taxonomy_term_data}, there was an entry with revision_id = 0 and tid = 91385. I looked for tid 91385 in {taxonomy_term_data_revision} but it wasn't there.
taxonomy_term_load(91385) didn't work for me, so as taxonomy_term_delete(91385), so I just removed this entry from {taxonomy_term_data} and this issue gone after that.

But I do not want it to happen again. Any idea why this could happen?

I am also getting this error. It happens when I try to add a term to an existing vocabulary list. I was able to add terms without problems with the code released available in May 2014. I have no custom modules. Just "out of the box" Commerce. All modules are up to date. So I believe this problem should not be listed as "closed".

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0' for key 'revision_id': INSERT INTO {taxonomy_term_data} (vid, name, description, format, weight) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => Fall 2014 Symphony Concert [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => filtered_html [:db_insert_placeholder_4] => 0 ) in drupal_write_record() (line 7364 of /srv/bindings/700d389adff64ec7a6de79e4acf9906d/code/includes/common.inc).

As a temporary solution I changed the index type 'unique' to 'index'.

Hi,

I will try to find some time this week to check it.

I figured out that In my case the problem was in implementation of hook_taxonomy_term_insert() in custom module.
Custom function did not work propeprly and was calling

exit;

@skippyT I just got off the phone with @paulgrantham about this particular problem and we got to the bottom of it. He had disabled (but not uninstalled) the taxonomy_revision module. this leaves all of the db fields (such as revision_id) in place, but does not provide the code to populate it when queries are composed, thereby throwing this error after a second term is created post taxonomy_revision being disabled.

There really should be a hook_disable() (https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...) in the taxonomy_revision.install file with some fix that either removes revision_id from the schema, or drops/alters the index on revision_id or leaves revision_id as an auto incrementing field that does not default to 0.

I've the same problem, after upgrade my drupal 7 to 7.34

Adding a link to a patch that might help with this (although the bug I experienced was not quite the same as described here).

@netw3rker: you are right, I reproduced the issue too, I will propose a patch for this today.

@netw3rker: the hook_disable is easy to write:

/**
 * Implements hook_disable().
 */
function taxonomy_revision_disable() {
  db_drop_index('taxonomy_term_data', 'revision_id');
}

But after the hook_enable will be a little bit to complicated. Because if the module was disabled before, new terms were created and we have also some terms with existing revisions, it is extremly hard to add revision ids for those terms without the revision id set.

I don't think we should manage this. If someone disables the module the index should be dropped manually and I don't recommend to do this on production server.

What do you think?

Ignoring this puts a lot of weight on people being able to go in and manage their database (and understand what that means) and a lot of risk on them cleaning it up correctly.

I think dropping the index is fine, and reassuring the index is pretty easy. It's worth pointing out that technically this is already done by force populating the revision table on install. It should just happen again on enable. I think it can pretty easily happen by doing 3 things:

1) remove any oprhan records from the term_revisions table
2) create new revision records for any terms that have been updated (detectable by a different in update date)
3) create new revision records for any new terms that have been created.

That can happen via 2 direct queries, or (while slower, more reliably) by iterating through the terms, and using the taxonomy save hooks.

make sense?

Check comment #20 for the latest version of this patch. Thanks.

The duplicate message is because you already have a term with revision_id=0 in your taxonomy_term_data table.
When you create a new term, it adds another one with revision_id=0, that results in the duplicate error.

We need to fix the term with revision_id=0.
This is a php snippet that can be run to fix it.

You can use devel module and go to /devel/php
Here you can copy/paste this code and run it.

// Get the term that has revision_id=0.
$term = db_select('taxonomy_term_data', 't')
    ->fields('t')
    ->condition('revision_id', 0)
    ->execute()
    ->fetchObject();
if (isset($term->tid) && $term->tid) {
  // Insert a new record in taxonomy_term_data_revision.
  $revision_id = db_insert('taxonomy_term_data_revision')
    ->fields(array(
      'tid' => $term->tid,
      'log' => '',
      'timestamp' => time(),
      'uid' => 1,
      'vid' => $term->vid,
      'name' => $term->name,
    ))
    ->execute();
}

if (isset($revision_id) && $revision_id) {
  // Update the revision_id of term.
  db_update('taxonomy_term_data')
    ->fields(array(
      'revision_id' => $revision_id,
    ))
    ->condition('tid', $term->tid)
    ->execute();
}

Then, you can apply the patch and everything should work ok.

Fix the patch to allow also creation of new revision when the option to create new revision is checked on term user interface.

I started getting this issue after updating the module to 7.x-1.3 as all taxonomy terms were being created with a revision ID of zero after the update. Reverting the module to 7.x-1.2 fixed the issue and started generating non-zero revision numbers again.

I also had to roll back to version to 7.x-1.2 until this issue is solved. It was show stopper for our production site.

it is fixed in dev version. can someone test it? if it is ok I will create a new release

I've upgraded to the latest dev version after hitting the issue with all new terms being added with a revision id of 0. Just confirming that this seems to have resolved the problem.

Hi,

Is this issue fixed and added to latest module download?
If I install now its gone?

I can confirm this have been fixed for me in the latest dev version.

Having the same issue, as mentioned in #23 this is a big issue for our production sites.
The latest dev release version does not fix the issue.
We have had to roll back to 7.x-1.2 until this issue is solved.
Happy to help test a new improved version.

AdamB: can you provide some more details? did you try the dev version?

thanks.

@skipyT, we applied the latest dev version; this created the same "Integrity constraint violation: 1062 Duplicate entry '0' for key 'revision_id'" error.

Update: We have applied the latest dev release & now additionally the patch mentioned in #21; this has fixed the issue and allows us to be able to add/edit/delete taxonomy items.

Confirmed.

Can we look at getting a new release created for this?

thanks ionut.alexuc for help, I didn't have time to work on this issue.

@skippyt It's good to see that at least one aspect of this issue has been resolved though but this still doesn't fix the 2nd part of this problem pointed out in #7 & #13 & #17.

This fix broke things for me. It is impossible to save a taxonomy term with "Create a revision" unchecked because 'revision_id' was removed as a primary key identifier to drupal_write_record.

Here is a patch to revert that. Like other patches, it still won't override if revision_id is not a proper number.-

Thank you, sarvab. That took care of it for me.

I just faced that issue with 1062 Duplicate entry '0' for key 'revision_id': INSERT INTO {taxonomy_term_data} etc. when adding new term to a vocabulary. I upgraded the module to --dev, tested - the same error. I patched with #21 and #37 - still error. Then I ran script from #20, tried to create term - term created. But then I tried to edit that new term - and I got page not found. So now I can see that term in term list of a vocabulary, but I can't reach neither it's page nor edit nor remove it.

This makes the module unusable so setting critical for now.

Agree with @axel.rutz

Agree, I actually stopped using it on all my projects because of this bug :(

Applied patch contains fix for the case when term is save and no revision is created.
It also contains a regression test for this case.

We was using this module but have to disable because this come out to be incompatible with https://www.drupal.org/project/editablefields which gives same error as sated above.

When I disabled this module after that it was not possible to add any new terms in my taxonomy as we was continuously getting this error whenever tried to add new term.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0' for key 'revision_id': INSERT INTO {taxonomy_term_data} (vid, name, description, format, weight, uuid, language) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => 6 [:db_insert_placeholder_1] => test term in category [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => filtered_html [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 969fcf27-dcf9-45a4-a429-9da607f1071c [:db_insert_placeholder_6] => und ) in drupal_write_record() (line 7376 of /var/www/site/includes/common.inc).

#43: code looks good, extra kudos for the tests!

#43 fixes the issue on 7.x-1.4. Thank you!

So rtbc per #46