Re: Updated wiki page for Database Changes

["bradford powell" <bradford powell gmail com>]

A few database thoughts...

I like the idea of having photo_versions being a relationship mapping
versions back to the originals, with versions being stored in the
photos table itself. Some useful benefits would be allowing different
versions to have different tags (for example, a cropped version of a
photo with Uncle Bob and Aunt June which no longer contains Uncle Bob
shouldn't have the 'Uncle Bob' tag.

A further suggestion for providing for future expansion to f-spot in
the non-destructive editing realm would be to have a string field in
the versions table which describes how the original was modified to
get to the version. The implementation of this would have to be worked
out, but it could be something like a GEGL graph or more simply a text
representation like "crop(30, 55, 300, 600)" or "gaussian(5)" or
"scale(0.5,0.5,bilinear)" or "dcraw(...)".

So version table could be something like:

CREATE TABLE photo_versions (
   base_photo INTEGER,
   result_photo INTEGER,
   modification STRING
)

But then how do we store info about the default version (the one that
shows in the GUI as the top of the stack)?

I'm just trying to open a bit of discussion about the database
changes. By reading through the list archives, it seems like some
plans for changes are in process, so hopefully through discussions we
can work out what those changes will be before they're made (since it
is a pain to change the schema).

-- Bradford