MariaDB 5 and 10 on Synology NAS

[digiman]

Hi,

some time ago I tried mariadb on my synology NAS. It was damn slow and I got
always error messages because I used it from Windows and Linux - finally I
switched back to SQlite.
So now I have two questions because I have now mariadb V10 additionally to
version 5 on the NAS available:
1.) Is Version 10 much faster so it is worth to give it a try and
2.) is the problem with Windows and Linux working on the same DB solved so
far?

Many thanks in advanced




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

2017-11-01 18:18 GMT+01:00 digiman <[hidden email]>:

Hi,

some time ago I tried mariadb on my synology NAS. It was damn slow and I got
always error messages because I used it from Windows and Linux - finally I
switched back to SQlite.
So now I have two questions because I have now mariadb V10 additionally to
version 5 on the NAS available:
1.) Is Version 10 much faster so it is worth to give it a try and

I use this kind of server on my host computer. It's enough fast to use but i don't pass through the local network (only the localhost).

My NAS has an older Mariadb (old Debian for ARM). It's incredibly slow. So it's same problem than you.

 

2.) is the problem with Windows and Linux working on the same DB solved so
far?

No. The way to identify a collection in database is based on UUID generated by KDE::Solid interface used everywhere in digiKam. under Linux you get right UUID, under Windows nothing, or not the same. Solid work perfectly under Linux. For MacOS, a huge patch is under validation into KDE bugzilla, but it's not yet officially committed. For Windows, Solid is full of holes in source code. This is the problem of KF5 framework where developers are not interested to support non Linux system.

A replacement of Solid do not exists yet, as in future Qt version. I follow the discussion, and digiKam is not alone in this case. Solid is a gateway to the computer device, and is well designed. So Solid need to be fully ported well for Windows, or, we need to use native Windows code inside digiKam, that is don't like very well.

The Collection path is problematic as Linux and Windows are different on this point. This is also a problem to solve (partially solved if UUID is the same for both system).

Gilles Caulier

Many thanks in advanced




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[digiman]

Well that's a clear statement - no need for change, even than if I would run only Linux PC's

Thanks Gilles!

Am 01.11.2017 um 19:03 schrieb Gilles Caulier:

2017-11-01 18:18 GMT+01:00 digiman <[hidden email]>:

Hi,

some time ago I tried mariadb on my synology NAS. It was damn slow and I got
always error messages because I used it from Windows and Linux - finally I
switched back to SQlite.
So now I have two questions because I have now mariadb V10 additionally to
version 5 on the NAS available:
1.) Is Version 10 much faster so it is worth to give it a try and

I use this kind of server on my host computer. It's enough fast to use but i don't pass through the local network (only the localhost).

My NAS has an older Mariadb (old Debian for ARM). It's incredibly slow. So it's same problem than you.

 

2.) is the problem with Windows and Linux working on the same DB solved so
far?

No. The way to identify a collection in database is based on UUID generated by KDE::Solid interface used everywhere in digiKam. under Linux you get right UUID, under Windows nothing, or not the same. Solid work perfectly under Linux. For MacOS, a huge patch is under validation into KDE bugzilla, but it's not yet officially committed. For Windows, Solid is full of holes in source code. This is the problem of KF5 framework where developers are not interested to support non Linux system.

A replacement of Solid do not exists yet, as in future Qt version. I follow the discussion, and digiKam is not alone in this case. Solid is a gateway to the computer device, and is well designed. So Solid need to be fully ported well for Windows, or, we need to use native Windows code inside digiKam, that is don't like very well.

The Collection path is problematic as Linux and Windows are different on this point. This is also a problem to solve (partially solved if UUID is the same for both system).

Gilles Caulier

Many thanks in advanced




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Andrew Goodbody]

On 01/11/17 18:03, Gilles Caulier wrote:
> The Collection path is problematic as Linux and Windows are different on
> this point. This is also a problem to solve (partially solved if UUID is
> the same for both system).

And it is this point that means the collection path would be better
placed in the rc file instead of the database. The collection path is
specific to the local machine and as such should be in the rc file. This
would make sharing the database across machines much simpler.

Andrew

[Mik Clucas]

It appears to me that putting the collection path into the rc file would solve the location issue between Linux and windows. Assuming that it is practiable to put the path into the rc file, would associating the collection with the UUID also in the rc file solve the Framework issue? Would it then be possible to use the same UUID for a collection between the 2 operating systems?

-------- Original message --------
From: Andrew Goodbody <[hidden email]>
Date: 02/11/2017 00:03 (GMT+01:00)
To: Gilles Caulier <[hidden email]>, digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]>
Subject: Re: MariaDB 5 and 10 on Synology NAS

On 01/11/17 18:03, Gilles Caulier wrote:
> The Collection path is problematic as Linux and Windows are different on
> this point. This is also a problem to solve (partially solved if UUID is
> the same for both system).

And it is this point that means the collection path would be better
placed in the rc file instead of the database. The collection path is
specific to the local machine and as such should be in the rc file. This
would make sharing the database across machines much simpler.

Andrew