SQL Databases from before 2.3.16

[John Ralls]

On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>> But we could add a row to the versions table with the last Gnucash
>> version to touch the database. When we write a change to the backend
>> that changes the way data are stored, we can invoke a routine that
>> reads everything in the old way and writes it back out the new way,
>> then updates the gnucash entry in the versions table. Older versions,
>> not knowing what newer versions have changed, would have to punt with
>> an error dialog ("Sorry, the database has been written by a newer
>> version of Gnucash. This version can't safely read it.") It would get
>> unwieldy in pretty short order (like the scrub routines in engine),
>> but we could do it.
> 
> I think you're right that this is almost exactly like a "Check &
> Repair."  The "Check & Repair" function exists to fix bugs that cause
> broken data to enter the database.  In this particular case, I don't
> think we need to prevent older versions from reading a database that was
> "checked & repaired" by a newer version of GnuCash.  It's perfectly
> reasonable to expect that older versions can read newer versions.

It isn't just "fixing bugs" or "broken data". The interpretation of data and the way it is stored will change as the program evolves. Such evolution should be transparent to the user so long as s/he moves only forward and stays with stable releases.

Testers working with unstable releases (even release candidates) must accept that storage representations can change and that it might be necessary, particularly early on when we're experimenting with new features or new storage modes, that they may have to go back to a stable-version-generated database and start over.

I guess it's OK for an older version to load a newer-versioned database if it's read-only, though it might misinterpret the stored data and do something wrong. (2.3.15 will happily load a 2.3.16-written database, but the slots will be hopelessly corrupt. r19911 can read a 2.3.15 database, but it can't put back the slots that 2.3.15 didn't write. Between r19729 and r19911, some slots that pre-19729 had stored weren't retrieved correctly.) 

If the older version is allowed to write to it, then we're back to the mixed-record problem or worse (lost data in the case of pre-2.3.16).

Anyway, if we're going to introduce the gnucash-version row, we should do it now, before 2.4 is released.

Regards,
John Ralls