[Digikam-devel] Future plans : 0.9.2-final and KDE4 port...

[Marcel Wiesweg]

> On Mon, 11 Jun 2007, Gilles Caulier wrote:
>
> [...]
>
> > This is want mean than DB structure will change in the future. We have
> > already a list of new informations to host in DB like :
> >
> > - Photo informations to perform search of images based on Exif/IPTC,
> > - GPS info to perform search of images on a map (imaging a bar where you
> > can query something like "i want to find all pictures taken around
> > Paris"), - Haar matrix to perform search of duplicate images (
> > http://scien.stanford.edu/class/ee368/projects2000/project12/4.html).
> > - Editor Actions List to perform non destructive edition of pictures
> > (technics used by Nikon NX soft for ex.)
> >
> > This is a small list of future informations hosted by DB. Others data can
> > be add of course and discussion is open about this subject (Arnd...).
>
> There is one important decision about the database:
> Will it be possible to easily add additional fields
>    - with new digikam releases (eg. 10.1, 10.2, ...)

If you look at amarok, they have had about 20 schema revisions.

We definitely plan to add more database fields. Adding a table with additional 
information is easy, it becomes more tricky if the change makes the database 
incompatible with previous versions. In this case, the application has to 
detect it and refuse to start.

As current versions cannot do this, my current plan is to move the db file to 
digikam4.db (where 3->4 nicely coincides with KDE3/KDE4) and any version from 
now on will be able to refuse to start if it does not understand the schema.
Users usually do not need to downgrade a version. If they have to, there'd be 
a severe regression which we should have fixed first ;-)
So the possible missing compatibility (not for all schema upgrades necessary ) 
mostly affects beta testers which might have a reason to use a stable 
version. In this case, we will make this clear in the release of beta1 - with 
schema changes only occuring in alpha state, and the option to specify 
different db files in config / on the command line.

>    - or even by the user

The problem is that the application at least needs to provide means to read 
and write the added values. If it does not know at all about the nature of 
the data, this will be only very basic support.

> ?
>
> Reason: new ideas might require new database fields.
> If this has to wait (like for example the GPS stuff right now),
> for a change from 0.10 to 0.11, this can delay such additions
> for a long time. If this is the case, then
> we really should  think very hard about additional fields
> for the database right now, to be able to leave it unchanged.
>
> However, if additions are simple and don't break
> anything (and this has to be absolutely guaranteed, IMO!),
> then only the additional fields needed right now should
> be added.