On Wed, 22 Feb 2012 20:52:54 -0500 Richard Hipp <d...@sqlite.org> wrote:
> Here <http://www.sqlite.org/cvstrac/wiki?p=UndoRedo> is a write-up > from 2005 in which I describe a technique I used to implement > unlimited-depth undo/redo in a application that used SQLite as its > file format. There was no "File/Save" button. But you could undo as > far back as you wanted - even in to prior sessions. Wonderful! Thank you very much for this reference. > That application was written in Tcl/Tk, but the idea works the same in > D or whatever language you want to use. OK. I hope we can continue asking here (despite using D) since there are no replies in D newsgroup where people are usually occupied replying to gigantic threads. :-) > Another approach is to record historical versions of rows in the > database somehow. In other words, design your schema as if it were a > Version Control System > <http://en.wikipedia.org/wiki/Revision_control> that keeps a > permanent record of past images of the data. Bonus points if you can > make it operate as a Distributed Version Control > System<http://en.wikipedia.org/wiki/Distributed_Version_Control_System>. Hmm, I must say it sounds intriguing although I'm not sure whether we really need it since once when we calculate the whole set of data for one 'person', it would not change much, iow. the data in the database are not so much prone to change as much we're interested to study/query relations between the data. > Note that Monotone <http://www.monotone.ca/> was a pioneer in the > DVCS space and their file format is an SQLite database. Note also > that SQLite itself is maintained using > Fossil<http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki>which > is another DVCS that uses an SQLite database for storage. (Yes, the > source code for SQLite is stored in an SQLite database. Recursion is > a wonderful thing.) Heh...my VCS really started with the Darcs and I used Monotone for some time - too bad it was too slow for Linus so world ended up with Git itself. ;) I did use Fossil for some time (and still looking what's going on) - it's very fine piece of software, but to make our life simpler we ended up using Mercurial along with hg-git when the needs arises. Having more interoperability features in Fossil (e.g. 2-way sync with other DVCS) would make it even more appealing, although it's questionable how much is this in sync with Fossil's objectives. ;) > Or, you could do all your work inside a transaction and then > implement a File/Save button that does a COMMIT for you. That > approach is conceptually simpler from the point of view of the > programmer. But it is less intuitive to users. I agree. > And if your application crashes, you lose all of your work done since > the last File/Save. Considering data won't change much, it might be sufficient. > If you do use this approach, please note that SQLite does support > nested transaction<http://www.sqlite.org/lang_savepoint.html>which > might be useful to you. Thank you very much. I was also not aware of that one...it's final time to start using those two books about Sqlite which I have. :-/ Sincerely, Gour -- Thus the wise living entity's pure consciousness becomes covered by his eternal enemy in the form of lust, which is never satisfied and which burns like fire. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
