Re: [Shotwell] Map Widget Update
- From: Joseph B <joseph bylund gmail com>
- To: Jens Georg <mail jensge org>
- Cc: shotwell-list <shotwell-list gnome org>
- Subject: Re: [Shotwell] Map Widget Update
- Date: Tue, 26 Jul 2016 07:57:09 -0400
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
tableThen 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?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]