Bug 276171 - Cannot migrate from mysql to mysql
Summary: Cannot migrate from mysql to mysql
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Migration (show other bugs)
Version: 2.0.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-21 08:46 UTC by Frederic Grelot
Modified: 2022-01-12 13:11 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Grelot 2011-06-21 08:46:36 UTC
Version:           2.0.0 (using KDE 4.6.4) 
OS:                Linux

This is created from bug #276052 (which describes actually 2 bugs).
When migrating from mysql to mysql (using different table names), the upgrade fails at "Create Schema".
This is due to the fact that SchemeUpdater tries to read the version number from the Settings table of the "toBackend", and uses this value in "SchemaUpdater::setVersionSettings()"

The following queries show the SchemeUpdater trying to read the version number, and come from the mysql log (digikam is the source database, while digikam2 is the target database) :
           92 Init DB    digikam
           92 Query    SET NAMES utf8
           93 Connect    digikam@laptop on digikam2
           93 Init DB    digikam2
           93 Query    SET NAMES utf8
           93 Query    DROP TABLE IF EXISTS AlbumRoots, Albums,
DownloadHistory, FilePaths, ImageComments, ImageCopyright, ImageHaarMatrix,
ImageInformation, ImageMetadata, ImagePositions, ImageProperties, ImageTags,
Images, Searches, Settings, Tags, TagsTree, Thumbnails, UniqueHashes
           94 Connect    digikam@laptop on digikam2
           94 Init DB    digikam2
           94 Query    SET NAMES utf8
           94 Query    CREATE TABLE IF NOT EXISTS PrivCheck
                (
                    id   INT,
                   name VARCHAR(35)
                )
           94 Query    ALTER TABLE PrivCheck DROP COLUMN name
110619 15:37:02       94 Query    CREATE TRIGGER privcheck_trigger AFTER DELETE
ON PrivCheck
                  FOR EACH ROW BEGIN
                  END
           94 Query    DROP TRIGGER privcheck_trigger
           94 Query    DROP TABLE PrivCheck
           94 Query    DROP TABLE IF EXISTS PrivCheck
           94 Quit    
           93 Query    select table_name from information_schema.tables where
table_type = 'BASE TABLE'
           93 Query    SELECT value FROM Settings WHERE keyword='DBVersion'
           93 Query    SELECT value FROM Settings WHERE
keyword='DBVersionRequired'
           92 Quit    
           93 Quit   

Reproducible: Didn't try

Steps to Reproduce:
-Have a mysql database (from version 1.9)
-migrate it with digikam 2.0.0b6 to another mysql DB

Actual Results:  
No migration : error while creating schema
Comment 1 Frederic Grelot 2011-06-23 08:18:33 UTC
I tested lots of things for this bug, and I think the solution was to add the following to the databasecopymanager.cpp, right after the "Migrate_Cleanup_DB" :
if (toDBbackend.execDBAction(toDBbackend.getDBAction("CreateDB"), bindingMap) != DatabaseCoreBackend::NoErrors)
    {
        emit finished(DatabaseCopyManager::failed, i18n("Error while creating the target database."));
        fromDBbackend.close();
        toDBbackend.close();
        return;
    }

Strangely enough, I think the database was not being created without this... (But still, the same code worked with SQLite, doesn't it?)
Comment 2 Francesco Riosa 2011-06-28 21:47:18 UTC
fixed in 2.0.0-rc
Comment 3 Ignatius Reilly 2011-09-15 21:14:48 UTC
I met with exactly the same problem while trying to migrate DK 1.9 with mysql to DK 2.0, then to 2.1.

Soon after installing DK 1.9, I had switched from sqlite to mysql. The migration was flawless.

Identical mysql log as reported by Frédéric Grelot

My set-up:
Ubuntu 11.04
Mysql 5.1
mysql user: root with password
mysql data on a NTFS volume

I don't consider this as fixed

Could someone comment and attach the mysql migration script, so that we could execute it manually for further testing?
Comment 4 Ignatius Reilly 2011-09-21 16:38:58 UTC
Update to my comment #3:

I tried to move the mysql data dir to an ext4 file system instead of NTFS.

Same problem, so NTFS is not the culprit.

THIS BUG IS NOT RESOLVED