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

John Ralls jralls at ceridwen.us
Mon Dec 5 19:59:12 EST 2011


On Dec 5, 2011, at 12:32 PM, Christian Stimming wrote:

> Am Freitag, 18. November 2011, 22:59:05 schrieb Geert Janssens:
>>> It
>>> means you cannot use invoice KVP as long as the XML file claims it can
>>> be
>>> read by 2.4.x without loosing information. If this is true but we still
>>> want to add a new data field to invoices, we would better change the XML
>>> structure directly so that an older gnucash will refuse to load the file
>>> altogether. That's still better than silently loosing data upon loading
>>> in 2.4.x...
>> 
>> Yes that's probably true. Quite unfortunate though...
>> 
>> Would it be a reasonable compromise to implement the invoice kvp parts in
>> 2.4 xml backend instead ?
> 
> No, that's not sufficient. If there isn't any release out there that contains 
> code that is able to read it, you should implement the xml part so that all 
> existing releases will refuse to load this file, if these data parts are being 
> used. Hence, in this particular situation your new data field should be a 
> normal XML element, and you need to add the xml reading code to the 2.4 branch 
> right now. Then, an upcoming 2.4.9 will contain this and correctly read and 
> write this field.
> 
> However, any earlier version (2.4.x or 2.2. or earlier) will refuse to load a 
> file that contains this data field. In this particular case, we can't do 
> anythin better because if it were a xml kvp, the earlier versions read the 
> file but suffer silent data loss (due to the erroneously missing invoice kvp 
> parser).
> 
>> I know that would only move the problem to 2.2.x,
>> but I don't think we support backward compatibility over past two major
>> releases.
> 
> Right. Backward compatibility in the sense that old versions should be able to 
> read newer files needs to be maintained only over the last major release.
> 
>> The kvp I'm introducing is only relevant if you really do use
>> credit notes. If you stick to invoices only, it doesn't matter if the kvp
>> is present or not, or even if it's lost in a save by an older version of
>> gnucash.
> 
> That's right, but nevertheless the old existing releases still don't know 
> about this data field. They must be forced to refuse those files that contain 
> this field.
> 
>> So:
>> - if no credit note is in the data file:
>>  2.2 can work on the file, but will lose any invoice kvp potentially
>> created by 2.6
> 
> Yes, and this data loss we cannot allow. So: 2.2 must refuse to load it if the 
> credit note field is in there.
> 
>>  2.4 can work on the file, and will keep any invoice kvp already present,
>> but won't create new ones.
> 
> You must distinguish here between <= 2.4.8 and >= 2.4.9. The former is in the 
> same situation as 2.2. The latter is fine with the newly introduced data 
> field.
> 

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. 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.

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.

Regards,
John Ralls




More information about the gnucash-devel mailing list