Aren't there different levels of backwards compatibility in play here? Backwards compatibility of the API and making sure begin/commit/rollback processes work the same with old and new versions is not the same as having the ability to take a crashed SQLite db including it's rollback journal and recover it using an older version of SQLite.
Personally I don't see why the rollback journal, which is by definition a very temporary file, needs to be backwards compatible such that the journal created on a new version of SQLite can be rolled back using an old version of SQLite. Under what circumstances would an older version of SQLite be used to rollback a newer journal? If backwards compatibility of the journal is required, then couldn't it be implemented in a way that a "master" journal is created for the entire transaction (including nested transactions) so if the db crashes and an old version of sqlite is used to recover it only the master journal is visible and thus the entire transaction is rolled back? Thanks, Sam ------------------------------------------- We're Hiring! Seeking a passionate developer to join our team building products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 9:52 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] SQLite and nested transactions It may be more difficult to implement this in a backwards-compatible way such that older versions of SQLite can rollback a journal created by a newer version if it encounters one. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
