SQL Version

[John Ralls]

On Feb 1, 2011, at 9:11 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>>> Yeah, I saw that as I was going through the patches after I sent this.
>>> How is this any different than just setting a number in
>>> e.g. gnc-sql-schema-version.h?  A developer still needs to remember to
>>> update the nano-version any time they make a schema change..
>>> 
>>> But the current method also means that gnucash 2.4.2 and 2.4.3 would
>>> consider themselves different even if the schema does not change.
>> 
>> Yes, it does still depend on a developer remembering to increment the
>> nano-version if he changes something (and as I keep pointing out, it
>> can be a change in engine, business, or qof, not just the schema). But
>> remember that there are two components: The actual version which last
>> touched the database (Gnucash version) and the GNC_RESAVE_VERSION
>> which marks the boundary for too-new and too-old. Too-old will force a
>> resave, too-new will force read-only. That's currently declared in
>> gnc-backend-sql.h; I should probably move it to configure as well so
>> that it's more visible.
> 
> Sorry, when I say "schema" I really mean "syntax and semantics of the
> storage", so I do (mentally) include the interpretation of the data in
> there when I say it.  I'm not really a DB person so I'm sure I'm
> mis-using the term.  So let's coin a new term, the "Interpretation
> Value" or "IV" of the database?
> 
> Any time the IV changes we have to be careful.  But if the IV has not
> changed then does the actual version of GnuCash matter?
> 
> Newer versions of GnuCash can certainly read older IVs and and offer the
> choice to open read-only or upgrade to the current IV (or potentially
> stay at the current IV, if the code thinks it can do so).  Older
> versions of GnuCash may not be able to read newer IVs, but could offer
> to open read-only and re-save at an older IV, but that could introduce
> data loss.
> 
> I still don't see why we need to tie anything to the GnuCash version?
> 

You can't really compare older (pre-aql) versions because the XML backend always writes out the entire dataset at every save. 

If the IV hasn't changed then we don't need to worry about it. But often we find that the IV did change after the fact from user testing. If we discover that there was a change from three versions ago that does cause trouble, then we can change GNC_RESAVE_VERSION to that and force a full resave for anything before that change. I do see that there's a flaw in the current implementation, though, because it updates the version id every time it saves; it should do that only for a complete save.

We don't need to tie to the Gnucash version, it's just convenient. 

Regards,
John Ralls