GNOME Bugzilla – Bug 745737
Database migration broken
Last modified: 2015-03-06 16:48:36 UTC
Running f21 (tracker 1.2), tracker master built on jhbuild. If I have a tracker database still untouched by 1.3.x (I had to recreate it here through /usr/bin/tracker-control -rs), data is indexed/stored correctly: excerpt from tracker-info some.ogg: 'nfo:averageBitrate' = '160.0' 'nfo:duration' = '302' At this point, if tracker-store from the jhbuild prefix is run (I did /usr/bin/tracker-control -t ; jhbuild run $BUILD/libexec/tracker-store), the database becomes completely broken. Excerpt from jhbuild's "tracker info" command, same ogg: 'nfo:averageBitrate' = 'nfo:averageBitrate' 'nfo:bitrateType' = 'nfo:bitrateType' 'nfo:codec' = 'nfo:codec' 'nfo:count' = 'nfo:count' 'nfo:duration' = 'nfo:duration' 'nfo:encodedBy' = 'nfo:encodedBy' 'nfo:genre' = 'nfo:genre' 'nfo:lastPlayedPosition' = 'nfo:lastPlayedPosition' 'mtp:creator' = 'mtp:creator' 'mtp:credits' = 'mtp:credits' 'nmm:dlnaMime' = 'nmm:dlnaMime' 'nmm:dlnaProfile' = 'nmm:dlnaProfile' 'nmm:genre' = 'nmm:genre' 'nmm:skipCounter' = 'nmm:skipCounter' This includes properties that weren't even there before
The difference is: With 1.2.x: [carlos@anacleto tracker]$ sqlite3 ~/.cache/tracker/meta.db SQLite version 3.8.8.3 2015-02-25 13:29:11 Enter ".help" for usage hints. sqlite> .schema nfo:Media CREATE TABLE "nfo:Media" (ID INTEGER NOT NULL PRIMARY KEY, "nfo:count" INTEGER, "nfo:count:graph" INTEGER, "nfo:duration" INTEGER, "nfo:duration:graph" INTEGER, "nfo:compressionType" INTEGER, "nfo:compressionType:graph" INTEGER, "nfo:hasMediaStream" INTEGER, "nfo:hasMediaStream:graph" INTEGER, "nfo:bitDepth" INTEGER, "nfo:bitDepth:graph" INTEGER, "nfo:codec" TEXT COLLATE TRACKER, "nfo:codec:graph" INTEGER, "nfo:encodedBy" TEXT COLLATE TRACKER, "nfo:encodedBy:graph" INTEGER, "nfo:bitrateType" TEXT COLLATE TRACKER, "nfo:bitrateType:graph" INTEGER, "nfo:averageBitrate" REAL, "nfo:averageBitrate:graph" INTEGER, "nfo:genre" TEXT COLLATE TRACKER, "nfo:genre:graph" INTEGER, "nfo:equipment" INTEGER, "nfo:equipment:graph" INTEGER, "nfo:lastPlayedPosition" INTEGER, "nfo:lastPlayedPosition:graph" INTEGER, "nmm:genre" TEXT COLLATE TRACKER, "nmm:genre:graph" INTEGER, "nmm:skipCounter" INTEGER, "nmm:skipCounter:graph" INTEGER, "nmm:dlnaProfile" TEXT COLLATE TRACKER, "nmm:dlnaProfile:graph" INTEGER, "nmm:dlnaMime" TEXT COLLATE TRACKER, "nmm:dlnaMime:graph" INTEGER, "nmm:uPnPShared" INTEGER, "nmm:uPnPShared:graph" INTEGER, "mtp:credits" TEXT COLLATE TRACKER, "mtp:credits:graph" INTEGER, "mtp:creator" TEXT COLLATE TRACKER, "mtp:creator:graph" INTEGER); After 1.3.x stomped: sqlite> .schema nfo:Media CREATE TABLE "nfo:Media" (ID INTEGER NOT NULL PRIMARY KEY); sqlite> Looking at the code, the database migration code seems to think the nfo:Media table is unaltered, so things break after as it's actually preparing a CREATE TABLE statement, which is left unfinished. I'm attaching a patch fixing this, seems to me like we want to behave as if !in_update in this case as we're creating the table from scratch (besides additional renaming/dumping/deleting), which is precisely what in_alter is describing there. I've tested with the 1.2->1.3 ontology changes and other supported ones locally and it all seems to work fine with the patch.
Created attachment 298724 [details] [review] tracker-data-manager: Re-creating tables don't add any property column If, during database update, the migration code chose to create a table from scratch, dumping data from the original one (eg. removing columns for properties that now have maxCardinality>1 and move to their own table), the destination table would be missing virtually all fields. When this happens, in_update differs from in_alter (the former tells whether we're creating the DB from scratch, the latter whether we're altering the original table). As we're actually creating the table from scratch, we must behave as such when dealing with the affected properties.
Attachment 298724 [details] pushed as 7f0afd8 - tracker-data-manager: Re-creating tables don't add any property column
If anyone fell into this, I'm afraid the solution is erasing the DB and indexing from scratch, this can be done through: tracker reset -r tracker control -s