[digikam] [Bug 355831] New: MySQL Schema Improvements

[bugzilla_noreply]

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

Richard Mortimer <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #95690|0                           |1
        is obsolete|                            |
  Attachment #95691|0                           |1
        is obsolete|                            |

--- Comment #17 from Richard Mortimer <[hidden email]> ---
Created attachment 95731
  --> https://bugs.kde.org/attachment.cgi?id=95731&action=edit
Updated trigger removal patch for MySQL databases

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #18 from Richard Mortimer <[hidden email]> ---
I have not had chance to look at MySQL upgrade procedure yet - although given
the changes made so far it should just be adding foreign keys so assuming that
the data is not broken due to orphaned records then that should be OK.

Similarly I have not had chance to look at the tags issue on MySQL yet.

A couple of other things I have noticed:

1 - Each of the image, thumbnails and face recognition databases all have a
table called Settings. I can see this causing trouble with all three merged
into a single database. At a very minimum the migration needs to take care to
track this and migrating back to separate databases would be even harder. Is it
going to be feasible to rename the thumbnails and face recognition tables to
something like SettingsThumb and SettingsFace or would that cause too much
trouble with SQLite support?

2 - Currently migration does not seem to handle the faces and thumbnails
databases. Presumably this is planned but just not done yet.

3 - the logic surrounding m_isStopProcessing in coredbcopymanager.cpp looks to
be wrong in places. The loops do a OR operation, e.g. "m_isStopProcessing || i
>=0", but not all of them test m_isStopProcessing to terminate the migration if
that flag is set.

Also using that way to terminate the loop the migration the code must be
careful not to access the loop counter "i" before terminating because it could
cause an overflow of the tables array if the termination is received during the
processing of the last table being iterated.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #19 from Richard Mortimer <[hidden email]> ---
(In reply to Richard Mortimer from comment #17)
> Created attachment 95731 [details]
> Updated trigger removal patch for MySQL databases

I forgot to note that the current patch still does not handle the deferred copy
of the icon value in the Albums table.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #20 from [hidden email] ---
>1 - Each of the image, thumbnails and face recognition databases all have a table called Settings. >I can see this causing trouble with all three merged into a single database.

Which trouble exactly ? I already noticed some problem and i fixed this with
face recognition DB integration.

>At a very minimum the migration needs to take care to track this and migrating back to separate >databases would be even harder. Is it going to be feasible to rename the thumbnails and face >recognition tables to something like SettingsThumb and SettingsFace or would that cause too >much trouble with SQLite support?

I thinking about to do the same. I think it's safe if Settings table differ
than SQlite for MySql.

2/ => ok.

3/ => the logic is good. turning on the bool value will stop copy processing.
But in fact an new method need to be add in this class to be able to change
this private bool member from outside (as for ex, when Cancel button is
pressed).

Granularity of bool check to cancel copy must be decreased. typically checking
bool outside the loop will prevent to break partial database copy in the middle
section of data.

In all case a garbage collector must be implemented to cleanup previous copy
while migration. Perhaps to cleanup target database can be enough.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #21 from Richard Mortimer <[hidden email]> ---
(In reply to caulier.gilles from comment #20)
> >1 - Each of the image, thumbnails and face recognition databases all have a table called Settings. >I can see this causing trouble with all three merged into a single database.
>
> Which trouble exactly ? I already noticed some problem and i fixed this with
> face recognition DB integration.
>
Sorry. That was a poor description from me. I was not referring to a specific
problem. I meant that it is likely to cause confusion/problems in the future.

> 3/ => the logic is good. turning on the bool value will stop copy
> processing. But in fact an new method need to be add in this class to be
> able to change this private bool member from outside (as for ex, when Cancel
> button is pressed).
As I said the current code code is broken in at least 2 places. They are easy
to fix but I just wanted to record it before I forgot.

The specific issues I can see are:

If set during the "Delete all tables" loop the loop will never terminate
(m_isStopProcessing || i>=0 will always be true) and will result in a crash
once "i" becomes negative and underflows the tables array.

Similarly if set during the copying the last iteration of the copy tables loop
then "i" will become greater than the length of tables and will result in a
crash during emit stepStarted because it tries to access tables[i].
>
> Granularity of bool check to cancel copy must be decreased. typically
> checking bool outside the loop will prevent to break partial database copy
> in the middle section of data.
agreed.

>
> In all case a garbage collector must be implemented to cleanup previous copy
> while migration. Perhaps to cleanup target database can be enough.
agreed. The user must expect that the target database has been changed and a
cleanup should be enough.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #22 from Richard Mortimer <[hidden email]> ---
Created attachment 95746
  --> https://bugs.kde.org/attachment.cgi?id=95746&action=edit
Defer migration of Albums.icon until after the Images table has been migrated

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #23 from Richard Mortimer <[hidden email]> ---
Created attachment 95747
  --> https://bugs.kde.org/attachment.cgi?id=95747&action=edit
Fix array under/overflow when m_isStopProcessing is set to true

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #24 from Richard Mortimer <[hidden email]> ---
Created attachment 95755
  --> https://bugs.kde.org/attachment.cgi?id=95755&action=edit
Move Thumbnail database Settings to ThumbSettings for  MySQL

This allows the thumbnail and main image databases to be contained within the
same MySQL database.

Also ensure that thumbnail MySQL tables use the InnoDB storage engine and not
the older MyISAM engine.

I had to change the longtext fields to varchar(767) to stop MySQL complaining
on upgrade. But also note that those same fields have a 255 character long
unique index so in practice anything over 255 characters is likely to cause
problems.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #26 from [hidden email] ---
Git commit e380a053a5273130e65b2d13976261cd9ca1a90a by Gilles Caulier.
Committed on 26/11/2015 at 21:50.
Pushed by cgilles into branch 'master'.

apply patch #95747 to pezvznt array overshoots in loop when cancel is applied.

M  +13   -8    libs/database/coredb/coredbcopymanager.cpp

http://commits.kde.org/digikam/e380a053a5273130e65b2d13976261cd9ca1a90a

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #95747|0                           |1
        is obsolete|                            |

--- Comment #25 from [hidden email] ---
Comment on attachment 95747
  --> https://bugs.kde.org/attachment.cgi?id=95747
Fix array under/overflow when m_isStopProcessing is set to true

>From 61762e8ed5083c791d553ddc43f278c7e08b54eb Mon Sep 17 00:00:00 2001
>From: Richard Mortimer <[hidden email]>
>Date: Wed, 25 Nov 2015 21:10:23 +0000
>Subject: [PATCH 3/3] Ensure that m_isStopProcessing does not cause array
> overshoots
>
>---
> libs/database/coredb/coredbcopymanager.cpp | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
>diff --git a/libs/database/coredb/coredbcopymanager.cpp b/libs/database/coredb/coredbcopymanager.cpp
>index e2f3115..e3cbf09 100644
>--- a/libs/database/coredb/coredbcopymanager.cpp
>+++ b/libs/database/coredb/coredbcopymanager.cpp
>@@ -126,7 +126,8 @@ void CoreDbCopyManager::copyDatabases(const DbEngineParameters& fromDBParameters
>
>     for (int i=(tablesSize - 1); m_isStopProcessing || i >= 0; --i)
>     {
>-        if (toDBbackend.execDirectSql(QString::fromUtf8("DROP TABLE IF EXISTS %1;").arg(tables[i])) != BdEngineBackend::NoErrors)
>+        if ( m_isStopProcessing ||
>+             toDBbackend.execDirectSql(QString::fromUtf8("DROP TABLE IF EXISTS %1;").arg(tables[i])) != BdEngineBackend::NoErrors)
>         {
>             emit finished(CoreDbCopyManager::failed, i18n("Error while scrubbing the target database."));
>             fromDBbackend.close();
>@@ -135,7 +136,8 @@ void CoreDbCopyManager::copyDatabases(const DbEngineParameters& fromDBParameters
>         }
>     }
>
>-    if (toDBbackend.execDirectSql(QString::fromUtf8("DROP TABLE IF EXISTS Settings;")) != BdEngineBackend::NoErrors)
>+    if ( m_isStopProcessing ||
>+         toDBbackend.execDirectSql(QString::fromUtf8("DROP TABLE IF EXISTS Settings;")) != BdEngineBackend::NoErrors)
>     {
>         emit finished(CoreDbCopyManager::failed, i18n("Error while scrubbing the target database."));
>         fromDBbackend.close();
>@@ -162,7 +164,9 @@ void CoreDbCopyManager::copyDatabases(const DbEngineParameters& fromDBParameters
>
>     for (int i=0; m_isStopProcessing || i < tablesSize; ++i)
>     {
>-        emit stepStarted(i18n(QString::fromUtf8("Copy %1...").arg(tables[i]).toLatin1().constData()));
>+        if (i < tablesSize) {
>+            emit stepStarted(i18n(QString::fromUtf8("Copy %1...").arg(tables[i]).toLatin1().constData()));
>+        }
>
>         // Now perform the copy action
>
>--
>2.5.0
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #27 from [hidden email] ---
Richard,

I start to test step by step all pending patches.

> For patch : Remove trigger dependency for MySQL.
==> the patch do not touch the dbsettingswidget.cpp code where SQL requirements
is given to previously create the databases in remote Mysql server by the
system admin.
==> This give a lots of error on the console when i use Mysql internal server
(i don't yet tested Mysql remote server yet). Note that Mysql Internal server
use "digikam" database name for all database (Core, Thumbs, Face). Look errors
below :

digikam.dbengine: Failure executing query:
 "UPDATE Tags SET icon=? WHERE id=?;"
Error messages: "QMYSQL3: Unable to execute statement" "Cannot add or update a
child row: a foreign key constraint fails (`digikam`.`Tags`, CONSTRAINT
`Tags_Images` FOREIGN KEY (`icon`) REFERENCES `Images` (`id`) ON DELETE SET
NULL ON UPDATE CASCADE)" 1452 2
Bound values:  (QVariant(qlonglong, 0), QVariant(int, 1))
digikam.dbengine: Failure executing query:
 "UPDATE Tags SET icon=? WHERE id=?;"
Error messages: "QMYSQL3: Unable to execute statement" "Cannot add or update a
child row: a foreign key constraint fails (`digikam`.`Tags`, CONSTRAINT
`Tags_Images` FOREIGN KEY (`icon`) REFERENCES `Images` (`id`) ON DELETE SET
NULL ON UPDATE CASCADE)" 1452 2
Bound values:  (QVariant(qlonglong, 0), QVariant(int, 2))
digikam.dbengine: Failure executing query:
 "UPDATE Tags SET icon=? WHERE id=?;"
Error messages: "QMYSQL3: Unable to execute statement" "Cannot add or update a
child row: a foreign key constraint fails (`digikam`.`Tags`, CONSTRAINT
`Tags_Images` FOREIGN KEY (`icon`) REFERENCES `Images` (`id`) ON DELETE SET
NULL ON UPDATE CASCADE)" 1452 2
Bound values:  (QVariant(qlonglong, 0), QVariant(int, 3))
digikam.dbengine: Failure executing query:
 "UPDATE Tags SET icon=? WHERE id=?;"
Error messages: "QMYSQL3: Unable to execute statement" "Cannot add or update a
child row: a foreign key constraint fails (`digikam`.`Tags`, CONSTRAINT
`Tags_Images` FOREIGN KEY (`icon`) REFERENCES `Images` (`id`) ON DELETE SET
NULL ON UPDATE CASCADE)" 1452 2
Bound values:  (QVariant(qlonglong, 0), QVariant(int, 4))
digikam.dbengine: Failure executing query:
 "UPDATE Tags SET icon=? WHERE id=?;"
Error messages: "QMYSQL3: Unable to execute statement" "Cannot add or update a
child row: a foreign key constraint fails (`digikam`.`Tags`, CONSTRAINT
`Tags_Images` FOREIGN KEY (`icon`) REFERENCES `Images` (`id`) ON DELETE SET
NULL ON UPDATE CASCADE)" 1452 2
Bound values:  (QVariant(qlonglong, 0), QVariant(int, 5))
...

and more...

> For patch : Defer migration of Albums.icon until after the Images table has been migrated

==> sound like it need the previous patch to be applied. the patch is rejected.
Did you confirm ?

> For patch : Move Thumbnail database Settings to ThumbSettings for MySQL

==> We need the same solution for Face database which also create a Settings
table.
==> sound like it need the previous patch to be applied. the patch is rejected.
Did you confirm ?
==> After renaming Thumb and Face DB Settings tables, this will fix bug #331628
? At least, as you specify InnoDB database engine, TokuDB engine will be not
possible to use instead. Right ?

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #28 from Richard Mortimer <[hidden email]> ---
(In reply to caulier.gilles from comment #27)
> Richard,
>
> I start to test step by step all pending patches.
>
> > For patch : Remove trigger dependency for MySQL.
> ==> the patch do not touch the dbsettingswidget.cpp code where SQL
> requirements is given to previously create the databases in remote Mysql
> server by the system admin.
OK. I haven't looked at internal MySQL yet. I've got quite a few MySQL database
servers hanging around so it is easier for me to test and debug there in the
early stages.

> ==> This give a lots of error on the console when i use Mysql internal
> server (i don't yet tested Mysql remote server yet). Note that Mysql
> Internal server use "digikam" database name for all database (Core, Thumbs,
> Face). Look errors below :

Did those errors cause the migration to fail? Or did it complete with just the
complaints on the console?

>
> digikam.dbengine: Failure executing query:
>  "UPDATE Tags SET icon=? WHERE id=?;"
> Error messages: "QMYSQL3: Unable to execute statement" "Cannot add or update
> a child row: a foreign key constraint fails (`digikam`.`Tags`, CONSTRAINT
> `Tags_Images` FOREIGN KEY (`icon`) REFERENCES `Images` (`id`) ON DELETE SET
> NULL ON UPDATE CASCADE)" 1452 2
> Bound values:  (QVariant(qlonglong, 0), QVariant(int, 1))

Those errors look like there are some Tags that have icons setup to point at
non-existant images. The examples you gave all have the first bound value as
zero which is typically a non-existant icon (instead of null). I suspect
most/all are set to zero instead of null. We should be able to filter out those
definitely bad ones.

What are your thoughts on filtering out data that is broken because the Album,
Image, Tag it refers to does not exist in the database? I tend to think that
the data was not accessible to users in the original database so it should be
safe to not transfer it.

> > For patch : Defer migration of Albums.icon until after the Images table has been migrated
>
> ==> sound like it need the previous patch to be applied. the patch is
> rejected. Did you confirm ?
Ah sorry. I rebased my patches based on what you had already committed to the
public git and squashed updates on a single topic into a single patch. I
thought it best to make the patch in bugzilla be clear about that whole changes
for a particular reason.

>
> > For patch : Move Thumbnail database Settings to ThumbSettings for MySQL
>
> ==> We need the same solution for Face database which also create a Settings
> table.
Yes. I did not get around to that yet. Am I correct in that we can assume no
need to provide an upgrade here because there are no existing MySQL users with
face settings yet.

> ==> sound like it need the previous patch to be applied. the patch is
> rejected. Did you confirm ?
Yes. It does require the previous patch.

> ==> After renaming Thumb and Face DB Settings tables, this will fix bug
> #331628 ? At least, as you specify InnoDB database engine, TokuDB engine
> will be not possible to use instead. Right ?
Hmmm. A difficult problem. Really we just want to NOT use MyISAM because it
does not support referential integrity.

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.

Richard

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #29 from [hidden email] ---
>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.

>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.

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 ?

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #30 from Richard Mortimer <[hidden email]> ---
(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.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #31 from [hidden email] ---
Richard,

With your Core DB schema update, this bug wil be fixed ?

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

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #32 from [hidden email] ---
Richard,

Same question than comment #31 abou this file :

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

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #33 from [hidden email] ---
Richard,

What's about to use Foreign Keys in DB schema ?

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

It's safe since Mysql and MariaDb support it ?

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #34 from [hidden email] ---
Richard,

I think file

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

... is fixed since a while. Can you confirm ?

Gilles

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

Richard Mortimer <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #95755|0                           |1
        is obsolete|                            |

--- Comment #35 from Richard Mortimer <[hidden email]> ---
Created attachment 95823
  --> https://bugs.kde.org/attachment.cgi?id=95823&action=edit
Standalone MySQL Thumbnail settings to ThumbSettings table

Move Thumbnail database Settings to ThumbSettings for MySQL

This allows the thumbnail and main image databases to be contained within the
same database.

Also ensure that thumbnail MySQL tables use the InnoDB storage engine and not
the older MyISAM engine.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[bugzilla_noreply]

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

--- Comment #36 from Richard Mortimer <[hidden email]> ---
Created attachment 95824
  --> https://bugs.kde.org/attachment.cgi?id=95824&action=edit
Standalone MySQL face recognition settings to FaceSettings table

Update face recognition MySQL support.

Use FaceSettings table to allow shared database in MySQL.
Use InnoDB engine to ensure that foreign key relationships are enforced.
Use foreign key between Identities and IdentityAttributes.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel