La mise à jour d'une colonne indexée FTS renvoie «ID innodb fts doc non valide»

Question

Environnement:

• Ubuntu 12.04 (et 13.04)
• Mysql 5.6.11

J'ai une table qui a un index de texte intégral dessus (la vraie table a beaucoup plus de colonnes et de lignes):

DROP TABLE IF EXISTS articles;
CREATE TABLE articles (
  FTS_DOC_ID BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  id INT NOT NULL ,
  title VARCHAR(200),
  body TEXT,
  UNIQUE KEY (FTS_DOC_ID)
) ENGINE=InnoDB;
CREATE FULLTEXT INDEX idx on articles (title);

INSERT INTO articles(id,title,body) 
  VALUES (9, 'MySQL Tutorial','DBMS stands for DataBase ...');

La documentation MySQL suggère de créer le FTS_DOC_ID (avec la bonne syntaxe) pour éviter une reconstruction de table complète.

Jusqu'à présent, tout va bien et je peux interroger en utilisant le MATCH...AGAINST Pour utiliser l'index FTS. Cependant, lorsque j'ai besoin de mettre à jour une colonne indexée:

UPDATE articles set title = 'New MySQL Tutorial'  WHERE id=9;

J'ai un:

Error code 182, SQL state HY000: Invalid InnoDB FTS Doc ID

Si je m'occupe manuellement de cette colonne comme ceci:

UPDATE articles a1, (SELECT MAX(FTS_DOC_ID)+1 AS ftsid FROM articles) a2
set title = 'New MySQL Tutorial', FTS_DOC_ID=ftsid  WHERE id=9;

Ensuite, la mise à jour est terminée. Mais ce n'est pas acceptable car j'ai plusieurs processus en parallèle qui mettent à jour ce tableau (bien que toutes les lignes différentes) et le risque est d'obtenir la même chose ftsid dans différents processus. Notez que la mise à jour du body La colonne qui n'est pas indexée par l'indice FTS n'a pas ce comportement. C'est à dire:

UPDATE articles set body = 'Info: DBMS stands for DataBase ...' WHERE id=9;

Mettez à jour avec succès la base de données.

Est-ce le comportement attendu? Ou est-ce un bug?

j'ai trouvé un punaise Rapporté dans la liste de bug MySQL sur le cas opposé (ne peut pas mettre à jour une colonne indexée non indexée mais peut sur un FTS indexé) mais pas ce cas.