[Digikam-devel] database fields in the future

[Marcel Wiesweg]

> > If (2) is more flexible and useable by plugins that sounds like a plus
> > to me...
>
> For me this is the biggest thing.
>
> At the moment (as has long been discussed), I would really like a way to
> store key/value pairs from plugins against "items" and "albums"
> (including virtual albums - e.g. tag views, searches etc.)
>
> For me a key/value pair is enough and things like format conversion
> (storeing floats/integers can just be done in the plugin).

For you as a plugin author, this is of course the way to go because an API 
shared by multiple applications cannot define any sort of database schema, 
and the application cannot provide a database table specific for one plugin.
We do have a table

CREATE TABLE ImageProperties
 (imageid  INTEGER NOT NULL,
  property TEXT    NOT NULL,
  value    TEXT    NOT NULL,
  UNIQUE (imageid, property));

right now, there is no problem to implement a kipi method to store values on 
images, and for albums a similar table can be added.

>
> I guess ultimately an interface like kconfig would do fine and could
> actually make the implementation in e.g. digikam quite simple - it just
> needs to store a big block of XML and we're laughing. A simple extension
> of kconfig for this purpose should suffice. WDYT?
>
> OK it's not as uber flexible as allowing plugins to add fields but it's
> a lot more transparent in terms of the kipi API.... unless I've totally
> misunderstood and you were referring to Digikam plugins rather than kipi
> plugins........ :S
>
> Col