On Wed, Sep 29, 2010 at 1:05 PM, Jim Nelson <[email protected]> wrote: > >> This means that Shotwell, and photo.db in particular are ripe for all kind >> of mashups. Some quick tests reveal that adding a table, adding a column >> to PhotoTable (a blob column, putting a 300k file in it) ... all this >> abuse doesn't >> phase Shotwell, it seems very tolerant. This is good. >> >> I'm not going to code in Vala, but I look forward to lots of Python >> which accesses >> the data in photo.db. Sqlite is pretty near data franca these days. Lots >> of >> hooks for us at the fringe to work with. > > I would mention that we treat photo.db as a private data store, in the sense > that we might change the schema at any time or the semantics of the database > (i.e. how some of the data is interpreted).
Right, code which went right to photo.db would expect to adapt to your schema, and know enough not to change the data Shotwell depends on. Good news is that Shotwell seems to tolerate extra stuff it doesn't know about. > > Also, Shotwell does not access the database in a transactional manner. If > you modify the database while Shotwell is running, bad things can happen, > including lost data. Right, anyone fool enough to do what I'm proposing would understand that if they break it they get to keep all the pieces. More information is on our wiki: > http://trac.yorba.org/wiki/ShotwellArchDatabase Is it possible to enable a persistent transaction journal for photo.db? Thanks, Kent > > -- Jim > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
