-
Matěj Laitl authored
I believe that the old lyrics table structure was more or less a mistake: TABLE lyrics ( id INTEGER PRIMARY KEY, -- actually never used in code url VARBINARY(324), -- actually a rpath from urls table lyrics TEXT ) Apart from data duplication and non-conformity to the "update anomaly" requirement of the database design, there was additional problem that rpath itself is not unique. The (deviceId, rpath) is. This change makes the lyrics table look more sane: TABLE lyrics ( url INTEGER PRIMARY KEY, -- points to url.id column lyrics TEXT ) with an effort to transition existing entries. The transition of 5000 lyrics entries takes 16s on my 2.5 GHz Core i5 (one core used), so it should be acceptable. This is the first time I'm changing db structure, I'd be glad to receive thorough review, namely of the update13to14() method and especially the duplicate-removing query. This is critical because database-corrupting fault would leave many Amarok users in a state where they would need to drop their database to make Amarok working again. ChangeLog of the unrelated iPod fix is updated because DB_VERSION bump triggers full collection rescan as far as it is documented. BUG: 242350 FIXED-IN: 2.6 REVIEW: 104966
5bf3f7be