2017-02-11, 19:38
Good. Enjoy Krypton 
Some notes for myself over this:
Log showed
This kind of migration failure seems to be a random MySQL quirk. It is discussed on https://github.com/xbmc/xbmc/pull/11530, where it happended to another user. He thought that the index definition was the issue
CREAT_E UNIQUE INDEX idxArtist1 ON artist(strMusicBrainzArtistID(36)
But this unique index has existsed on the artist table since Frodo, db version 32, when Mbids were added to the schema. It will prevent any records being inserted or the artist table updated in any way that violates it. Hence the data should cause any problems when the same index is created in the new db after migration.
The actual error was
this says that MySQL is rejecting a repeated NULL, not some duplicated mbid, and yet it normally allows unique indexes to have NULL values. This is very common in the artist table. Changing the index to 255 would not have avoided rejection of duplicate NULL.
The only mention I could find on Google was that a few other applications had MySQL randomly complain about duplicate NULLs, but all were fine on retry. The suggestion is db corruption of some kind solved by export, recreate, and import. That would explain why having imported it I could migrate from Hetfiled's 59 without any problem.
The index on MySQL will not allow with both aaf09f31-bb5c-43e5-9f54-bb6554c33a71 and aaf09f31-bb5c-43e5-9f54-bb6554c33a71/2a5b713c-839e-4392-b344-59829ec77613 to exist as the first 36 chars are the same (the example given on the aborted PR). But it is worth noting that SQLite does not support length parameters on indexes, so a SQLite db will allow those records to coexist, but equally they would not violate the creation of analytics on migration to a new db schema. Need to make this more consistent - either limit the field length varchar(36) not TEXT, and/or ensure that any programatic comparisons use 36 char.
We do need to see if we can change things in v18 so that the failed migration is more obvious.
Some notes for myself over this:
Log showed
Code:
NOTICE: Attempting to update the database music60 from version 59 to 60
ERROR: SQL: [music60] Undefined MySQL error: Code (1062)
Query: CREAT_E UNIQUE INDEX idxArtist1 ON artist(strMusicBrainzArtistID(36))This kind of migration failure seems to be a random MySQL quirk. It is discussed on https://github.com/xbmc/xbmc/pull/11530, where it happended to another user. He thought that the index definition was the issue
CREAT_E UNIQUE INDEX idxArtist1 ON artist(strMusicBrainzArtistID(36)
But this unique index has existsed on the artist table since Frodo, db version 32, when Mbids were added to the schema. It will prevent any records being inserted or the artist table updated in any way that violates it. Hence the data should cause any problems when the same index is created in the new db after migration.
The actual error was
Code:
ERROR 1062 (23000): Duplicate entry 'NULL' for key 'idxArtist1'The only mention I could find on Google was that a few other applications had MySQL randomly complain about duplicate NULLs, but all were fine on retry. The suggestion is db corruption of some kind solved by export, recreate, and import. That would explain why having imported it I could migrate from Hetfiled's 59 without any problem.
The index on MySQL will not allow with both aaf09f31-bb5c-43e5-9f54-bb6554c33a71 and aaf09f31-bb5c-43e5-9f54-bb6554c33a71/2a5b713c-839e-4392-b344-59829ec77613 to exist as the first 36 chars are the same (the example given on the aborted PR). But it is worth noting that SQLite does not support length parameters on indexes, so a SQLite db will allow those records to coexist, but equally they would not violate the creation of analytics on migration to a new db schema. Need to make this more consistent - either limit the field length varchar(36) not TEXT, and/or ensure that any programatic comparisons use 36 char.
We do need to see if we can change things in v18 so that the failed migration is more obvious.
