[Digikam-users] Database inconsistencies

Jean-François Rabasse jean-francois.rabasse at wanadoo.fr
Wed Dec 12 14:17:53 GMT 2012


On Wed, 12 Dec 2012, Remco Viëtor wrote:

> I agree that it's a bad idea to modify a DB 'by hand'. But, could the
> non-removal in cascade be a speed concern (limiting the number of small
> actions on the data base)? Not deleting some data in cascade doesn't seem to
> cause problems, except poluting the data base with inaccessible data.

Well, yes and no. It's a pollution, you're right, but it can cause problems
in case of reuse of identifiers.
Imagine you have an image with id xxx, and a related comment referencing
that id. The image gets destroyed, the comment no.
In a future a new image is created with (available) id xxx, and the
garbage comment gets reconnected.

Database integrity constraints should be a sine qua non condition.
But, as for SQLite3, the tool has weaknesses and we must be aware of
that.

> And a while ago someone posted the following to check and compact
> the SQLite data base:
> ...

I remember, the « someone » was me :-)

But it's a matter of cleanup, not a regular guaranty. I don't know
what trust level can be set on a software « integrity\_check » when
the same software doesn't handle integrity properly. :-)

My personal philosophy is that, in the case of DK, the database isn't
that much important IF there's a safe storage for meta information.
Editing metadata is work and time, using a database is only a fast tool
for future searches.
If metadata is archived into the image XMP section, all images become
independant of the DK software, version, and it's always possible to
wipe out the database and rebrowse from scratch.
(Or use metadata with other applications.)

Regards,
Jean-François


More information about the Digikam-users mailing list