sql versioning (was Re: Next release 2.4.1? Branching stable and trunk sooner or later?)

[John Ralls]

On Jan 20, 2011, at 3:00 PM, Phil Longstaff wrote:

>          On Thu, 2011-01-20 at 13:49 -0800, John Ralls wrote:
>> There are two things I'd like to get done before we release 2.4.1: I'd like to complete the version control for the sql backend (and I found yesterday that I've a bit more work to do on enforcing read-only on the qofbook)
> 
> What are your requirements for version control?  How will you be
> extending the current simple
> each-table-has-a-version-and-when-opened-the-db-is-updated going to be
> modified?

From r20123:

> * Add a macro GNC_RESAVE_VERSION which holds an svn revision number. 
> * When fully saving a database put this number in versions with 
>  table_name Gnucash-Resave.
> * On database load, compare the current GNC_RESAVE_VERSION with the 
>  Gnucash revision and Gnucash-Resave revision saved when the database 
>  was created. 
> * If the current GNC_RESAVE_VERSION > the saved Gnucash 
>  version, then emit ERR_SQL_DB_TOO_OLD.
> * If GNC_RESAVE_VERSION < the saved Gnucash-Resave, emit ERR_SQL_DB_TOO_NEW.


Recall that the versions table entry "Gnucash" gets updated to the current svn version at every write (r19920).

The next part is that when gnc_post_file_open encounters a  TOO_OLD it will offer the user the choice of resaving everything with the current data format or continuing with the book marked read-only; a TOO_NEW will just make the book read-only. A save-as will clear the read-only by creating a new book.

I still have some work to do with enforcing read-only: my first try, which makes qof_instance_edit_begin return FALSE, crashes quite reliably.

The underlying reason, of course, is that while the table revision code handles changes in the schema for a table, its easy for changes in the various core modules to change the what the data in the table means, quite transparent to the backend. These changes have been dealt with with scrub functions in engine (and probably in other places that I haven't found yet), but that depends upon the xml backend's behavior of writing out the whole dataset every time. This is an attempt to make that assumption valid for the sql backend as well. 

Regards,
John Ralls