[Digikam-devel] [Bug 276052] Failed to update the database schema from version 5 to version 6

[Frederic Grelot]

https://bugs.kde.org/show_bug.cgi?id=276052





--- Comment #2 from Frederic Grelot <fredericg_99 yahoo fr>  2011-06-19 15:54:57 ---
My last message may have been wrong : the problem at database migration seems
to be different with that of database upgrade.
At startup, when Digikam tries to upgrade the database scheme, the log is as
follow :

110619 15:48:05      191 Connect    digikam at laptop on digikam
          191 Init DB    digikam
          191 Query    SET NAMES utf8
          191 Quit    
          192 Connect    digikam at laptop on digikam
          192 Init DB    digikam
          192 Query    SET NAMES utf8
          193 Connect    digikam at laptop on digikam
          193 Init DB    digikam
          193 Query    SET NAMES utf8
          193 Query    CREATE TABLE IF NOT EXISTS PrivCheck
                (
                    id   INT,
                   name VARCHAR(35)
                )
110619 15:48:06      193 Query    ALTER TABLE PrivCheck DROP COLUMN name
          193 Query    CREATE TRIGGER privcheck_trigger AFTER DELETE ON
PrivCheck
                  FOR EACH ROW BEGIN
                  END
          193 Query    DROP TRIGGER privcheck_trigger
          193 Query    DROP TABLE PrivCheck
          193 Query    DROP TABLE IF EXISTS PrivCheck
          193 Quit    
          192 Query    select table_name from information_schema.tables where
table_type = 'BASE TABLE'
          192 Prepare    SELECT value FROM Settings WHERE keyword=?
          192 Reset stmt    
          192 Execute    SELECT value FROM Settings WHERE keyword='DBVersion'
          192 Close stmt    
          192 Prepare    SELECT value FROM Settings WHERE keyword=?
          192 Reset stmt    
          192 Execute    SELECT value FROM Settings WHERE
keyword='DBVersionRequired'
          192 Close stmt    
          192 Query    BEGIN WORK
          192 Query    CREATE TABLE IF NOT EXISTS ImageHistory
                            (imageid INTEGER PRIMARY KEY,
                             uuid VARCHAR(128),
                             history LONGTEXT CHARACTER SET utf8)
          192 Query    CREATE TABLE IF NOT EXISTS ImageRelations
                            (subject INTEGER,
                             object INTEGER,
                             type INTEGER,
                             UNIQUE(subject, object, type))
          192 Query    CREATE TABLE IF NOT EXISTS TagProperties
                            (tagid INTEGER,
                             property TEXT CHARACTER SET utf8,
                             value LONGTEXT CHARACTER SET utf8)
          192 Query    CREATE TABLE IF NOT EXISTS ImageTagProperties
                            (imageid INTEGER,
                             tagid INTEGER,
                             property TEXT CHARACTER SET utf8,
                             value LONGTEXT CHARACTER SET utf8)
          192 Query    CALL
create_index_if_not_exists('ImageTags','tag_id_index','imageid')
          192 Query    ROLLBACK
          192 Prepare    REPLACE into Settings VALUES (?,?)
          192 Reset stmt    
          192 Execute    REPLACE into Settings VALUES ('DBVersion','5')
          192 Close stmt    

Fortunately, the whole operation is ROLLBACK'ed at the end. I'm not sure where
the problem is, but it may be related with the "create_index_if_not_exists"
call.
This functions seems to be manually-created from the last comment on the
following mysql doc page :
http://dev.mysql.com/doc/refman/5.1/en/create-index.html

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.