r21577 - gnucash/trunk/src/backend/xml - Fix xml backend to load and save invoice kvp values.

[Geert Janssens]

Op maandag 5 december 2011 16:59:12 schreef John Ralls:
> 
> There's a catch here: An XML file can have an element or not, and as long as
> the file isn't validated against a schema that declares the element
> mandatory (and Gnucash doesn't use schema validation AFAIK), if it's not
> there no problem, so 2.4.8 can read the file and be happy if there aren't
> any credit memos.
> 
> That's not the case with the SQL backend. There's no such thing as an
> optional field in a table, so the "safe version" number in configure.ac has
> to be bumped up and 2.4.8 and earlier will refuse to open the database --
> whether the feature is used or not.
> 
> The KVP load and store code has no idea what keys are there. This is true of
> both backends. If a newer version of Gnucash creates a new KVP key and
> writes it out and an older version then reads and writes the KVP, the older
> version will read in the new key and when the file is saved, write it back
> out again. (In the case of the SQL backend, if it doesn't write out the
> KVP, which can happen, see bug 642276, it won't delete the existing record.
> Either way, no harm.)
> 
> So the risk with KVP isn't loss of data, it's misinterpretation of data.
This isn't quite correct. The risk with this particular KVP really is loss of 
data. The XML backend in 2.4.x and earlier simply don't have code to save or 
load KVP slots for invoices. So any invoice KVP will be lost during a save in 
2.4.x. This is not so for the sql backends. They handle kvp correctly for all 
engine objects.

> If
> a credit memo appears like an invoice in an older version of Gnucash and
> causes transactions to be changed -- or even to look funny so the user is
> tempted to "correct" them, that's a problem that justifies blocking earlier
> versions from reading the file/database as Christian says.
> 
Agreed.

> One last thing: I don't think that we want to make a change breaking file/db
> compatibility in the middle of a release series. If it's required the
> feature should wait for 2.6 -- so we branch 2.5 soon and the one or two
> users who are loud about wanting the feature can use test versions.
> 
More on this later.

Geert