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

[Tibor Blenessy]

Julien Narboux wrote:
>> ((To me this example just highlights that it would be nice
>> to allow for easy additions of new fields in the
>> database in the future, i.e. withouth the need to wait for
>> a 0.9 to 0.10 transition ...))
>>   
> I think you are raising the right question. I am not a specialist of 
> databases.
> Currently, It seems to me that changing the database format is something 
> the developpers do not want to do too often and they rather want to wait 
> for major releases.
> That is why I proposed some field which may be useful only in a far 
> future. I understand as Gilles said that some fields are currently hard 
> to extract because in Makernote. But maybe one day these fields will be 
> in new version of the exif standard...
> Should these fields already be on the database right now even if they 
> are not filled  by Digikam and the corresponding features are not yet 
> implemented ?
> Would it be easier to add some fields during minor release (10.1 -> 
> 10.2) by adding  tables (picture_id, new_field) ?
> 
> My naive questions,
> 
> Julien

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.

So this thread, as I understand it, is about default rows in Fields 
table. Tags use almost same db schema now - they could be merged and 
tags can be viewed as user defined fields with no value and tree 
structure (in separate table representing tree relations). (and as I 
have proposed few days before, albums & groups can be treated same way).

Tibor Blenessy