[Digikam-users] Some questions about digikam4.db

[Jean-François Rabasse]

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 ?

JF