[Digikam-devel] [digikam] [Bug 355831] MySQL Schema Improvements

Richard Mortimer via KDE Bugzilla bugzilla_noreply at kde.org
Fri Nov 27 15:59:42 GMT 2015


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

--- Comment #30 from Richard Mortimer <richm+kde at oldelvet.org.uk> ---
(In reply to caulier.gilles from comment #29)
> >Did those errors cause the migration to fail? Or did it complete with just the complaints on the console?
> 
> ==> No migration here. As now first run assistant support Mysql as well, we
> can satrt to init a DB with Mysql as well. So, as schema is changed a lots,
> i always start tests with a fresh DB.

OK. I see the error now and what causes it. The AlbumDB::addTag routine in
albumdb.cpp gets passed an iconID value of zero. That presumably means "no
icon" but with referential integrity enabled the update fails because there is
no image zero in the database.

An easy solution would be to filter out any iconID = 0 values and set the icon
to null in those cases. It is not 100% safe because the database could decide
to use imageID = 0 for a real image but it would work in most cases.

I can see similar usages in setTagIcon plus the equivalent functions for Album
icons.

> 
> >TokuDB should work and it would be possible to manually change all the tables after upgrade.
> >If automatic support for a particular backend was required then I think it would have to be >specified on the setup/migration dialog and then manually specified during the migration.
> 
> ==> in fact i don't care about TokuDB engine. If we specify in table
> creation that Immno engine must be used as well, because we have tested with
> it only, it's fine for me.
> 
> The question is more to kill this bug with right comment, as TokuDB engine
> is not supported and digiKam use Inmmo engine. The goal is not to introduce
> complexity, it's already enough complex.
I think the correct answer is that we test and use InnoDB. There is nothing to
stop someone changing the engine to TokuDB and it should work (no guarantees)
but the engine may get changed back to InnoDB if/when digikam is upgraded.

> 
> As Mysql is able to support tables with different engines at the same time
> (fix me if i'm wrong), digiKam must be usable as well. Right ?
Yes.


I have produced a patch to use a "FaceSettings" table for faces. Would you like
me to produce clean patches against master to change both Face and Thumbnail
databases to the new settings. I think those two are less likely to break than
the main database code because they do not use null columns in quite the same
way as the album/tags icons tables.

Richard

-- 
You are receiving this mail because:
You are the assignee for the bug.



More information about the Digikam-devel mailing list