migrating from 4 to 5 and no database usable

[Luca Ferrari]

Hi all,
due to the explosion of my old computer I update digikam from the last
4 branch to the new 5.3 one as of kubuntu 16.10.
I've got all my stuff in digikam4.db (fully backupped for God sake!),
but when I start digikam 5.3 it is unable to find/migrate the
database.
A little inspecting points me to the fact it is trying to use mysql
(something I would like to avoid):

digikam.general: AlbumWatch use QFileSystemWatcher
digikam.general: Database Parameters:
   Type:                     ""
   DB Core Name:             ""
   DB Thumbs Name:           ""
   DB Face Name:             ""
   Connect Options:          ""
   Host Name:                ""
   Host port:                -1
   Internal Server:          false
   Internal Server Path:     "/home/luca/.local/share/digikam/"
   Internal Server Serv Cmd: "mysqld"
   Internal Server Init Cmd: "mysql_install_db"
   Username:                 ""
   Password:                 ""

QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 SKGSQLCIPHER
digikam.dbengine: Error while opening the database. Error details [
QSqlError("", "Driver not loaded", "Driver not loaded") ]
digikam.dbengine: Error while opening the database. Error details [
QSqlError("", "Driver not loaded", "Driver not loaded") ]
digikam.dbengine: Error while opening the database. Error details [
QSqlError("", "Driver not loaded", "Driver not loaded") ]
digikam.dbengine: Error while opening the database. Error details [
QSqlError("", "Driver not loaded", "Driver not loaded") ]
digikam.dbengine: Error while opening the database. Error details [
QSqlError("", "Driver not loaded", "Driver not loaded") ]


Now, if I go the settings and try to configure digikam to poin to the
sqlite3 digikam4.db it refuses to accept the setting (not allowing me
to press the OK button).
Am I missing some package?

Thanks,
Luca

[Chris Green]

Luca Ferrari <[hidden email]> wrote:
> Hi all,
> due to the explosion of my old computer I update digikam from the last
> 4 branch to the new 5.3 one as of kubuntu 16.10.
> I've got all my stuff in digikam4.db (fully backupped for God sake!),
> but when I start digikam 5.3 it is unable to find/migrate the
> database.

This surely points to having Digikam make it easy (default even) to
store *all* metadata with the images.  There is then no need to
migrate the database.

--
Chris Green
·

[Luca Ferrari]

On Thu, Dec 22, 2016 at 10:41 AM, Chris Green <[hidden email]> wrote:

> Luca Ferrari <[hidden email]> wrote:
>> Hi all,
>> due to the explosion of my old computer I update digikam from the last
>> 4 branch to the new 5.3 one as of kubuntu 16.10.
>> I've got all my stuff in digikam4.db (fully backupped for God sake!),
>> but when I start digikam 5.3 it is unable to find/migrate the
>> database.
>
> This surely points to having Digikam make it easy (default even) to
> store *all* metadata with the images.  There is then no need to
> migrate the database.

That's not a solution.
Anyway, I tried again and now digikam can accept my old database and
everything seems to be fine. Not sure what happened before.
Sorry, maybe a permission problem?

Luca

[Chris Green]

Luca Ferrari <[hidden email]> wrote:

> On Thu, Dec 22, 2016 at 10:41 AM, Chris Green <[hidden email]> wrote:
> > Luca Ferrari <[hidden email]> wrote:
> >> Hi all,
> >> due to the explosion of my old computer I update digikam from the last
> >> 4 branch to the new 5.3 one as of kubuntu 16.10.
> >> I've got all my stuff in digikam4.db (fully backupped for God sake!),
> >> but when I start digikam 5.3 it is unable to find/migrate the
> >> database.
> >
> > This surely points to having Digikam make it easy (default even) to
> > store *all* metadata with the images.  There is then no need to
> > migrate the database.
>
> That's not a solution.

Well it should be. ... or are you saying that you don't have all the
metadata in your images?

--
Chris Green
·

[Luca Ferrari]

On Thu, Dec 22, 2016 at 5:27 PM, Chris Green <[hidden email]> wrote:
> Well it should be. ... or are you saying that you don't have all the
> metadata in your images?

No, I don't.
Personally, even this should be avoided, I believe that having it in a
database is something useful.
While I understand that, when migrating, it could be easier to have
each image as more self contained as possible, you loose the
capability to automate some off-line bulk operations that can scan the
database itself. And, in the case of a network capable database, you
can have access from different workstations and, well, usual
networking stuff.
I believe that in the case of domestic usage sqlite or self contained
images are the best solutions, for a more complex environment a
database is the only choice.

Luca

[Chris Green]

Luca Ferrari <[hidden email]> wrote:
> On Thu, Dec 22, 2016 at 5:27 PM, Chris Green <[hidden email]> wrote:
> > Well it should be. ... or are you saying that you don't have all the
> > metadata in your images?
>
> No, I don't.
> Personally, even this should be avoided, I believe that having it in a
> database is something useful.

Absolutely, but why can't Dokuwiki keep the data in both places.  Keep
it in the image files for security (and portability), keep it in the
database for fast access and the ability to search/sort in various
ways.

I don't believe this would be a big speed penalty.

It should at least be configurable with the default being 'keep all data
in both places' with options to allow the user to do less than this if
speed or other requirements are more important.

--
Chris Green
·

Le 22/12/2016 à 19:27, Chris Green a écrit :

> Absolutely, but why can't Dokuwiki

I guess you mean Digikam

keep the data in both places.

it can, even in sidecar files

   Keep
> it in the image files for security

this may be very unsecure if the images are to be shared, many sensitive
data can be stored in metadata

jdd

[Luca Ferrari]

On Thu, Dec 22, 2016 at 7:44 PM, jdd <[hidden email]> wrote:
> this may be very unsecure if the images are to be shared, many sensitive
> data can be stored in metadata

+1
even if I have to admit that requiring a database (e.g., mysql) could
be another potential risk for inexperienced users.

Luca

[Chris Green]

jdd <[hidden email]> wrote:
> Le 22/12/2016 à 19:27, Chris Green a écrit :
>
> > Absolutely, but why can't Dokuwiki
>
> I guess you mean Digikam
>
Oops, yes, I use both.  :-)

> keep the data in both places.
>
> it can, even in sidecar files
>
>   Keep
> > it in the image files for security
>
> this may be very unsecure if the images are to be shared, many sensitive
> data can be stored in metadata
>

Ah, different sort of security.

Yes, I agree that if you export images you might want to remove some
of the metadata but surely that could become part of the export
process.

By 'security' I meant not losing any information associated with the
picture.  A database corruption could lose the data if it wasn't also
in the imagae file.

--
Chris Green
·

Le 23/12/2016 à 10:42, Chris Green a écrit :

> picture.  A database corruption could lose the data if it wasn't also
> in the imagae file.
>
yes. I mostly keep data in sqlite base, much easier to backup and to tie
with image collection. Mysql needs absolutely a serious backup (with a
dump in text form), not that easy to do.

I don't know neither what is the status of editing the collection path
in the base, I have from time to time to change the collection path (for
example to split the collection between several disks when size become
too big), and most of the time I end up with meta data in images and
database rebuild

jdd