Bug 267733

Summary: Automatical initialisation of Internal MySQL database doesn't work after digikam start
Product: [Applications] digikam Reporter: Zbynek Kocur <zokl>
Component: Database-MysqlAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: adam, caulier.gilles, riccardo, vivo75+kde, will_clardy, zokl
Priority: NOR    
Version: 1.9.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 2.0.0

Description Zbynek Kocur 2011-03-05 18:46:41 UTC
Version:           1.9.0 (using KDE 4.6.1) 
OS:                Linux

Automatical initialisation of Internal MySQL database doesn't work after digikam start. The Internal MySQL box in option menu is blank. Everything works perfect if the box of using the Internal MySQL database is checked. Any time, the DB test works.
The last information about using the MySQL Internal server is not stored.


Reproducible: Didn't try

Steps to Reproduce:
Restart Digikam.



OS: Linux (x86_64) release 2.6.37-gentoo-r1
Compiler: x86_64-pc-linux-gnu-gcc
Comment 1 Riccardo Iaconelli 2011-04-19 18:31:51 UTC
I can confirm this bug. It looks like digikam simply doesn't start the internal database upon startup. To fix this you only have to go into Settings, tick "Use internal database" and press "Ok".
Comment 2 Zbynek Kocur 2011-04-27 15:00:23 UTC
Hi your recomendation works but digikam doesn't store the settings and after restart you must set using internal database again.
Comment 3 Riccardo Iaconelli 2011-05-02 14:25:23 UTC
This is exactly why I commented on this bug, and have not closed it... :)
Digikam developers.. are you around?
Comment 4 Francesco Riosa 2011-05-09 16:59:31 UTC
@bug_id = 267733
@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
Comment 5 Riccardo Iaconelli 2011-05-09 20:00:42 UTC
Hi,
I'm sorry if this is a redundant comment, i didn't really try out your patch (need a stable digikam on this machine) but I just want to make sure this really fixes the "database doesn't autostart" issue.

What I mean is: this patch seems to address initialization/migration issues, or issues on recreating tables, but in this case the database works perfectly, it only seems that the mysqld binary is never actually invoked to act as a local server.

Then, maybe it's just me not knowing enough of this SQL XML things, or probably this really fixes things, but better a doublecheck than overlooking things. :)

I can obviously give more details if needed!
Comment 6 Francesco Riosa 2011-05-09 20:27:16 UTC
(In reply to comment #5)
> Hi,
> I'm sorry if this is a redundant comment, i didn't really try out your patch
> (need a stable digikam on this machine) but I just want to make sure this
> really fixes the "database doesn't autostart" issue.

Work here for me, but would like to see other success/failure reports.

To test new this new script is possible to install digikam from sources as user, leaving the system digikam stable, backup of ~/.kde* and digikam databases is needed tough.

There is a small guide in
https://bugs.kde.org/show_bug.cgi?id=258409#c8
would be very nice to see result of testing. Check 2.0 beta is running in the help menu.

> 
> What I mean is: this patch seems to address initialization/migration issues, or
> issues on recreating tables, but in this case the database works perfectly, it
> only seems that the mysqld binary is never actually invoked to act as a local
> server.

I've seen it invoked but failing initialization.

> 
> Then, maybe it's just me not knowing enough of this SQL XML things, or probably
> this really fixes things, but better a doublecheck than overlooking things. :)

you're welcome

> I can obviously give more details if needed!

if it still fail more details will be needed, for example run `kdebugdialog` and activate debug before starting, possibly also modifying mysql-global.conf to include 

log-output = FILE
general_log = 1
general_log_file = $HOME/tmp/general_log.sql

$HOME/tmp MUST have sufficient permission for the database to write into it
Comment 7 Riccardo Iaconelli 2011-05-10 10:46:29 UTC
digikam doesn't compile here: http://pastebin.com/A9pzymV4
I have libjpeg-turbo-devel-1.1.0-2.fc14.x86_64 installed, and CMake passes the test.
Comment 8 caulier.gilles 2011-05-10 10:51:15 UTC
JPEG TURBO is not yet supported. Look here for details :

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

Gilles Caulier
Comment 9 Riccardo Iaconelli 2011-05-10 11:06:07 UTC
ah, awesome. which library should I install then?
Comment 10 caulier.gilles 2011-05-10 11:11:12 UTC
standard libjpeg 6.x, 7.x or 8.x, available on all Linux system, Mac, and windows. JPEG turbo still experimental and cannot be considerated as stable for production...

Gilles Caulier
Comment 11 Riccardo Iaconelli 2011-05-10 11:34:47 UTC
for future reference - on fedora standard libjpeg is not avaliable: you just need to replace jpeglib.h with jconfig.h around line 150 of CMakeLists.txt

Anyways, this is what happens when I try to start the (uninstalled, beta) digikam:

An error occurred during the internal server start.
Details: 
Error while calling the database server starter.
Details: The name org.kde.digikam.DatabaseServer was not provided by any .service files
Comment 12 Riccardo Iaconelli 2011-05-10 11:38:03 UTC
Installing it doesn't change anything. I'll now do some tests and report the results of my findings.
Comment 13 Riccardo Iaconelli 2011-05-10 11:44:25 UTC
1) Start digikam from the command line. Error Box:

An error occurred during the internal server start.
Details: 
Error while calling the database server starter.
Details: The name org.kde.digikam.DatabaseServer was not provided by any .service files

2) Press "Ok", watch the konsole:

[ruphy@hilbert:digikam/build]$ digikam                                                                                                             (05-10 11:40)
digikam(23910)/digikam (core): Error while opening the database. Error details [ QSqlError(2002, "QMYSQL: Unable to connect", "Can't connect to local MySQL server through socket '/home/ruphy/.kde/share/apps/digikam/db_misc/mysql.socket' (2)") ] 
QSqlError(2002, "QMYSQL: Unable to connect", "Can't connect to local MySQL server through socket '/home/ruphy/.kde/share/apps/digikam/db_misc/mysql.socket' (2)") ] 
...

3) Try to open the config dialog, tick "internal server", and try to test a connection:

Database connection test was not successful. 
Error was: Can't connect to local MySQL server through socket '/home/ruphy/.kde/share/apps/digikam/db_misc/mysql.socket' (2) QMYSQL: Unable to connect

As a matter of facts, looking in there you find that there is no mysql.socket file.
Comment 14 Riccardo Iaconelli 2011-05-10 11:51:00 UTC
starting the server with the command line 
/usr/libexec/mysqld --defaults-file=/home/ruphy/.kde/share/apps/digikam/mysql.conf --datadir=/home/ruphy/.kde/share/apps/digikam/db_data/ --socket=/home/ruphy/.kde/share/apps/digikam/db_misc/mysql.socket

makes digikam see it.
Comment 15 Riccardo Iaconelli 2011-05-10 11:59:53 UTC
ok, so, I managed to "fix" my digikam problem by cp-ing my .kde folder over, manually starting a mysqld binary, and "migrate" the database to the internal database.
I still see

An error occurred during the internal server start.
Details: 
Error while calling the database server starter.
Details: The name org.kde.digikam.DatabaseServer was not provided by any .service files

at startup, but now things work perfectly. Is this bug really fixed? was it a problem with my local database, or some old configs left from god knows when?
Comment 16 Riccardo Iaconelli 2011-05-10 12:16:43 UTC
awesome, I think I managed to reproduce the problem. my laptop was suddendly turned off because of overheating, and digikam doesn't want to start the database anymore. Reopening this bug since this is a reproduceable failure.
Comment 17 Francesco Riosa 2011-05-10 13:57:02 UTC
(In reply to comment #16)
> awesome, I think I managed to reproduce the problem. my laptop was suddendly
> turned off because of overheating, and digikam doesn't want to start the
> database anymore. Reopening this bug since this is a reproduceable failure.

good, please add to .kde/share/apps/digikam/mysql.conf

[mysqld]
err-log  = <HOME>/.kde/share/apps/digikam/db_misc/mysql.err
log-error = <HOME>/.kde/share/apps/digikam/db_misc/mysqld.err

reason for mysql to not start are many and sparsed, need to see the log files
Comment 18 Francesco Riosa 2011-05-10 14:06:12 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > awesome, I think I managed to reproduce the problem. my laptop was suddendly
> > turned off because of overheating, and digikam doesn't want to start the
> > database anymore. Reopening this bug since this is a reproduceable failure.
> 
Forger previous comment, log_error=mysql.err is already present in the config file without path it should be in db_data directory, could you please post that?

thanks
Comment 19 caulier.gilles 2011-12-15 09:03:50 UTC
Riccardo,

Do you see last comment from Francesco ?

Gilles Caulier
Comment 20 Riccardo Iaconelli 2012-06-27 10:42:07 UTC
So, i think that for some reason I have missed some activity here.

Good news: I can't currently reproduce the bug, so I'd mark it as fixed. Let's reopen it if it pops up again. thumbs up. :)
Comment 21 Myriam Schweingruber 2012-08-25 15:05:37 UTC
*** Bug 305663 has been marked as a duplicate of this bug. ***