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

Tibor Blenessy tiborb at matfyz.cz
Sat Sep 1 08:34:43 BST 2007


Marcel Wiesweg wrote:
>> Correct me, if I'm wrong, but I think, that fields should be stored in
>> table like Fields (with cols: field_id, name, description?) and there
>> will be separate table FieldValues (image_id, field_id, value). To have
>> the ability to store some fields as numbers, int_value column can be
>> added to FieldValues and maybe some flag column to Fields table, to mark
>> that this field is numerical.
>>
>> For fields that require many-to-many relationship (multiple comments)
>> there will be more entries with same image_id and field_id but different
>> value.
> 
> What you describe is - thought to its end - just what strigi/nepomuk are 
> doing: storing of triples of information, and ontology to describe what can 
> and shall be stored for a type of file.
> 
> This is a very general approach.
> For digikam, I see the database more as a tool that we use rather than a 
> general description of the data, so we know what we store, what format it 
> has, and where it is stored.
> We must keep complexity low!

Now I more understand, your approach, thanks for explanation. But still 
I don't see any advantage from it. If nepomuk is doing the same, it will 
be great to define digikam ontology and use nepomuk for it. That way it 
will be much more future-proof. Other tools will be able to use 
digikam's tags for processing, ...

To known what we store, format and where it's stored - this info can be 
hardcoded in digikam src (in stl map or something similar). Nowadays it 
is hardcoded in SQL strings, so it's almost the same.


Tibor Blenessy

ps. maybe I don't understand it, because I don't understand digikam 
code, if that's true, reply rtfc (like rtfm, but c for code), and I'll 
be quiet :)




More information about the Digikam-devel mailing list