On 12 Jun 2017, at 17:33, Simon Slavin wrote: >> 1. Is it correct that schema changes are not tracked and can't be part of a >> changeset? So any ALTER TABLE command needs to be taken care about >> separately? > > Correct. Changing the schema means that changesets are no longer valid. You > will either need to make a system which can handle both, or regard schema > changes as points you cannot UNDO past.
As long as the schema changes in a way that the new schema is "bigger" than the old one, old changesets should still be applicable. I haven't tried it out though. >> 2. Changes to the VIEW query are not tracked too? So, when a view query >> changes, this is not part of the changeset. > > VIEWs, like INDEXes, are part of the schema. Changing a VIEW is changing the > schema. Ok, confirms my view. BTW: Is there a versioning/session extension that can track schema changes too? >> 3. We are thinking about supporting UNDO not only for the current session >> but for the live-time of a document. In this case we need to store the >> changeset blob into the database as well. > > But storing something in the database is changing the database! You would get > problems with recursion. Only if the table storing the changesets gets tracked too. Which can be avoided. So not tracking this particular changeset table should do the job. > Instead, you would have to store the blobs in another database. That would seem to work too, but we wouldn't have a "single file contains it all" setup anylonger. I will try to omit the changeset table and see if that works. >> 4. We haven't thought through all combinations but is the oder of UNDOs in a >> changeset relevant? So if I have a changeset do I have to apply it strictly >> in revers order in some cases to avoid constraint violations etc? > > Absolutely. Consider this sequence: > > INSERT a row > DELETE that row > > Now try to UNDO that sequence in the wrong order. You end up with a row > which wasn’t there. We use SQLite's INVERT function on changesets, which does the trick. I haven't looked at the code but assume that it applies the inverted actions in reverse order. > I cannot comment on using sessions to do this but I can suggest an > alternative which is compatible with more systems. This is that for every SQL > command you execute you provide one or more commands which would reverse the > effect. That's what SQLite constructs when creating an inverted changeset. That's what we use. -- Robert M. Münch, CEO M: +41 79 65 11 49 6 Saphirion AG smarter | better | faster http://www.saphirion.com http://www.nlpp.ch
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
