Bug 233770

Summary: Error messages after changing to mysql
Product: [Applications] digikam Reporter: Johannes Wienke <languitar>
Component: Database-MysqlAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: minor CC: arthur, Hamsi2k, vivo75+kde
Priority: NOR    
Version: 1.3.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Unspecified   
Latest Commit: Version Fixed In: 2.0.0
Sentry Crash Report:

Description Johannes Wienke 2010-04-08 21:07:49 UTC
Version:           trunk (using KDE 4.4.2)
Installed from:    Archlinux Packages

After changing the database settings to mysql using a database that was created with the migration tool beforehand, I see these messages on the console:

digikam(13449)/digikam (core): Call initializeThumbnailDatabase at application start. There are already thumbnail loading threads created, and these will not be switched to use the database.  
digikam(13449)/digikam (core): Call initializeThumbnailDatabase at application start. There are already thumbnail loading threads created, and these will not be switched to use the database.  
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Failure executing query:
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: "CREATE TABLE Settings         
                            (keyword LONGTEXT CHARACTER SET utf8 NOT NULL,
                             value LONGTEXT CHARACTER SET utf8,
                             UNIQUE(keyword(333)))
                 "
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Error messages: "Table 'Settings' already exists QMYSQL3: Unable to execute statement" 1050 2 "Table 'Settings' already exists" "QMYSQL3: Unable to execute statement" QSqlError(-1, "", "")
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Bound values:  ()
QSqlDatabasePrivate::removeDatabase: connection 'thumbnailDatabase-25238784' is still in use, all queries will cease to work.
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Failure executing query:
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: "CREATE TABLE Settings         
                            (keyword LONGTEXT CHARACTER SET utf8 NOT NULL,
                             value LONGTEXT CHARACTER SET utf8,
                             UNIQUE(keyword(333)))
                 "
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Error messages: "Table 'Settings' already exists QMYSQL3: Unable to execute statement" 1050 2 "Table 'Settings' already exists" "QMYSQL3: Unable to execute statement" QSqlError(-1, "", "")
digikam(13449)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Bound values:  ()

Doesn't look too healthy. ;) Is this desired? If yes, this will definitely confuse users.
Comment 1 Quallenauge 2010-04-13 19:58:51 UTC
Both thumbnails-DB and digikam-DB uses the same table "Settings".
All other tables have different names. Seems easy to fix, it is possible
to create a table only if they does not exists.

But I discovered the following problem:
When digikam tries to check, if there is already a thumbnails schema deployed
it does a
--------------------------
QStringList tables = m_access->backend()->tables();
if (tables.contains("Thumbnails"))
--------------------------

Also it does the same check for the digikam database:
--------------------------
QStringList tables = m_Backend->tables();
if (tables.contains("Albums"))
--------------------------

It seems correct to do this in that way and it does, if there is only
one schema at the database (which is the case for SQLite).
On MySql it's possible to have more schemas, e.g. you have a testing
schema and a stable schema. Additional the user "digikam" has access
to both of the schemas. Then the call
--------------------------
tables.contains("Albums")
--------------------------
returns true if at least in one of the schemas exists a table. That means,
the schema is not created and it would result in failed queries.
My proposal for this behaviour is to create database specific
queries to check if the digikam/thumbnail database is really
on the selected schema.
Comment 2 Francesco Riosa 2011-05-09 17:03:34 UTC
@bug_id = 233770
@bug_status = RESOLVED
@resolution = FIXED

Git commit ec7ceeea0d2587abb9f1bdd17109d4903998e943 by Francesco Riosa.
Committed on 09/05/2011 at 14:20.
Pushed by riosa into branch 'master'.

more resilient database upgrade and startup

All statements are made resilient to a partially upgraded database.
- CREATE TABLE are done with IF NOT EXISTS
- TRIGGERs are dropped and re-created
- a new stored procedure is added "create_index_if_not_exists"
  the procedure check in information_schema if the index exists,
  if not does create it
- all INDEXes are created using "create_index_if_not_exists"

BUG: 271924
BUG: 258409
BUG: 257183
BUG: 267733
BUG: 262231
BUG: 233770

M  +90   -56   data/database/dbconfig.xml.cmake     

http://commits.kde.org/digikam/ec7ceeea0d2587abb9f1bdd17109d4903998e943