[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 :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/0ef1283f8952d2d7173b8c3b3e8895e50d3da4d5


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