[digiKam-users] internal SQL Server error after Update to 7.10.0

[Peter Orth]

Hi Gilles,

I’m trying to understand this problem before upgrading from DK 7.9 on an M1 Mac OS 13.1

Here is my layperson’s understanding:  In finding a work-around for the problems that users experienced connecting to an external database on OS 13 Mac, some database handling changes were made in 7.10.  
Now, in order to continue to use Mysql Internal database on DK 7.10, I’ll need to follow the steps that you outlined below, migrating to SQLite in DK 7.9, then opening that database in 7.10 and migrating back to Mysql.
Does that sound roughly correct? 

Questions:

1. I have an internal database of 335K images. Will SQLite be able to handle a database of that size? I remember that SQLite is not recommended beyond a certain number of assets (100K)?

2. Will this workaround be necessary if I skip DK 7.10 and go straight to 8.0 (future) release?  I’m not currently using a remote database.

3. Clarification on step 3 below: "Rename the ".mysql.digikam" folder with ".bak" in your collection.”  What exactly is the resulting name, where does the “.bak” go? 
When performing the inverse operation in DK 7.10, this folder's name needs to revert to ".mysql.digikam”, or will a new folder be written?

4. I assume that switching databases Mysql>SQLite>Mysql will result in a very long (hours/days) rebuilds of the database. Is this the case?

5. If SQLite can handle the 330K images, is there a reason to go back to MariaDB/Mysql in 7.10 ? 


Thank you for your patience in indulging my knucklehead questions


Peter Orth
310 413 8267


> On Mar 13, 2023, at 9:09 AM, Gilles Caulier <caulier.gilles at gmail.com> wrote:
> 
> Hi Benjamin,
> The problem is due to a packaging bug from Macports used to compile
> whole digiKam.
> 
> Typically, digiKam use the Qt Sql driver to handle a database (as
> sqlite, mysql internal , and mysql server).
> 
> Since 2 digiKam release, the mysql server do not work anymore.
> initially, the mariabd version 10.15 from Macports was used since a
> version to deal with an internal or a remote mysql database. But this
> have been broken somewhere, and i don't found exactly the problem, but
> i suspect a qt bug.
> 
> I used an old mariadb 5.x version, and all work fine. The side effect
> is that internal mariadb database created with 10.15 cannot be read
> with the 5.x version. I don't found a script to go back from more
> recent mariadb contents to an older one.
> 
> So the solution is :
> 
> 1/ Go back to digiKam 7.9 and migrate your mariadb database to sqlite.
> 2/ Set the sqlite as your current database.
> 3/ Rename the ".mysql.digikam" folder with ".bak" in your collection.
> This directory host the mariadb database file.
> 4/ Go back to digiKam 7.10 and do the inverse to convert to the new
> mariadb format from sqlite.
> 
> See the long story from the bugzilla entry relevant of this problem :
> https://bugs.kde.org/show_bug.cgi?id=46See t2736
> 
> Best
> 
> Gilles Caulier
> 
> 
> Le lun. 13 mars 2023 à 15:28, Benjcmin v. Bohr <benjcmin at gmail.com> a écrit :
>> 
>> Hi,
>> 
>> after updating to 7.10.0 from 7.9.x via the internal update function on macOS.
>> I get an error message
>> 
>> Following error message:
>> ---------------------------
>> An error occurred during the internal server start.
>> 
>> Details: Database process exited unexpectedly during initial connection.
>> 
>> Executable:
>> /Applications/digiKam.org/digikam.app/Contents/lib/mariadb/bin/mysqld
>> 
>> Arguments: --defaults-file=/Users/Username/Library/Application
>> Support/digikam/digikam/mysql.conf,
>> --datadir=/Users/Username/Pictures/.mysql.digikam/db_data,
>> --basedir=/Applications/digiKam.org/digikam.app/Contents//lib/mariadb/,
>> --socket=/Users/Username/Library/Application
>> Support/digikam/digikam/db_misc/mysql.socket
>> 
>> Process error: Unknown error
>> -------------------------
>> 
>> I found an old [Bug 436624] Error during internal server start with the exact same issue.
>> As far as I understood that was a bug in the pkg, any advice?
>> 
>> MfG Benjamin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20230315/39c38783/attachment.htm>