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: 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? On Tue, Jul 26, 2016 at 3:29 AM, Jens Georg <[email protected]> wrote: > > Are schema changes frequently column addition only? If so would it >> make sense to expose previous schemas in views? I guess it's kind of >> an edge case that people are switching back and forth between schemas >> to test a new branch. >> > > How would you fix the schema versioning with a view? > -- 347-829-5863
_______________________________________________ shotwell-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/shotwell-list
