[Digikam-users] Some questions about digikam4.db

Gilles Caulier caulier.gilles at gmail.com
Thu Nov 10 13:04:05 GMT 2011

2011/11/10 Jean-Fran├žois Rabasse <jean-francois.rabasse at wanadoo.fr>

> On Thu, 10 Nov 2011, Anders Stedtlund wrote:
>  Hi,
>> My fault. Didn't mean to remove the thumbnails, just the db and have the
>> thumbnails in the filesystem instead.
>> The pro to have thumbnails in the same db as everything else must be that
>> it's possible to join over that table in a single run. Now I assume that
>> there's one query to find images and another query to find the thumbnails.
> You can issue joins with tables from different databases, if you "attach"
> another DB to your current handle.
>  attach another-base.db as nails;
> then
>  select .... from Images, nails.Thumbnails  where .. etc;
> But this will be "single run" only if you process scalar tuples attributes.
> With large size data, and thumbnails are, you could get a blob handle but
> to get the effective data (the image bytes) you need to load via the blob
> interface, sqlite3_blob_open(), sqlite3_blob_read(), sqlite3_blob_close()
> It's nothing but "hidden" file access, and the management is close to
> standard Unix I/O open(), read(), close().
> So, probably not really a pro. IMHO
> But it would be great if DK developers could just explain the reason why
> the 2 DB, master and thumbnails, of previous versions have been merged.
> What's the technical reason, what's the expected benefit ?
In my archive, i found the commit in source code from Marcel which
introduce the dysfunction about thumbnails archiving in main database :


Gilles Caulier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20111110/4530647d/attachment.html>

More information about the Digikam-users mailing list