Re: [Shotwell] Map Widget Update

[Jens Georg <mail jensge org>]

Sorry, meant to -list on the previous message (but now since other
> people may have interesting things to add).
>
> We'd still need schema versioning, though we could possibly extend
> the time between schema changes.  They'd still be necessary in the
> case of destructive schema changes (i.e. drop column).  I'm thinking
> something along the lines as:

That would mean getting rid of the explicit schema version number, no?

> CREATE VIEW schema_20 AS
> SELECT
>   all the columns you need to operate in schema 20
> FROM
>   table
>
> Then verify_database doesn't need to check for equality, it just
> needs to check that the view that it needs to operate exists. 
> upgrade_database would be on the hook to alter the underlying table
> and create the new view for a given version.  In the event the change
> was destructive probably delete the old views.  Per a commend in
> Db.vala:~135 it looks like we never truly drop columns.  We do stop
> writing to them, so they become stale, which means previous versions
> can no longer trust the contents of those columns.  It seems to me
> the safer route would be to drop the column so that an older version
> of the software doesn't read out data which is not populated by a
> newer version.  The comment is not untruthful about dropping columns
> being difficult in sqlite (here's a good example of how it seems to
> be done: http://grasswiki.osgeo.org/wiki/Sqlite_Drop_Column).  Since
> we'd only be dropping columns when we know we're breaking backwards
> compatibility we wouldn't need to remake old views to point to the
> new incarnation of the table (since versions of shotwell which would
> need those views would no longer work anyways).
>
> Does any of that make sense?  Anyone hanging out on irc these days?
Have to think about it. Dropping columns in SQLite is slightly
annoying, yes. I think I used something similar in Rygel to do this.

I'm (phako) usually on during evenings (CET)