[Digikam-devel] What do we want to store in the database?

[Gilles Caulier]

2007/8/31, Marcel Wiesweg <marcel.wiesweg at gmx.de>:
>
> > I think Multiple Comments is essential. But also comments need to be
> > qualified more than just a simple text stream. Gilles mentioned 4
> > strings to be stored but I'm not sure what they all are. My suggestion
> > would be:
> >  * Source
> >  * Who/Author
> >  * Language
> >  * Comment
>
> Gilles, was that what you meant with 4, a table for multiple comments with
> four columns like the ones above?


I thinking 4 (more if you want) different comments as UTF-8 strings. Nothing
special about that. We can use like we want, for example to store text in
many language, or text come different photographers.

You course this still to define more. What the advantage to use a table we
host all strings against 4 separate strings ?

>
> > Here the Source would 99.99% of the time be "Digikam" but hopefully this
> > interface can be exposed via e.g. Facebook/Flickr via Kipi plugin and
> > under these circumstances the Source would be set accordingly. Language
> > I think should be optional seeing as external comments may not have this
> > information associated with them.
> >
> > > - rating
> >
> > Tags, (as Gilles also pointed out). With the addition of a "region"
> > attribute (simple rect is probably sufficient here c.f. Facebook -
> > simplicity wins) as per http://bugs.kde.org/show_bug.cgi?id=146337
> >
> >
> > And another new one for you:
> > - key/value pairs
> >
> > Some form of generic key/value pair storage system for every image,
> > album and tag. This would be to allow 3rd party plugins via kipi store
> > important information/configuration paramaters. Actually, possibly more
> > sensible is a blob of data instread, in which we can store an XML
> > kconfig dump although this would not allow easy searching... (e.g. it
> > would be quite useful for a kipi plugin to say "give me all images with
> > foo = 42".
> >
> > This needs more discussion but I've often mentioned it in the past so
> > not a bolt from the blue.
>
> We already have a table for this. If libkipi required a method to store
> String/String pairs for an image, it would be easy to provide.


Colin, you will be happy to implemente it (:=)))

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070831/87b554ee/attachment.html>