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

[Alex Aycinena]

Geert,

> ---------- Forwarded message ----------
> From: Geert Janssens <janssens-geert at telenet.be>
> To: Derek Atkins <warlord at mit.edu>
> Cc: gnucash-devel at gnucash.org
> Date: Wed, 07 Dec 2011 17:15:32 +0100
>
> Subject: Re: r21577 - gnucash/trunk/src/backend/xml - Fix xml backend to load and save invoice kvp values.
> Op woensdag 7 december 2011 10:34:33 schreef Derek Atkins:
>> John Ralls <jralls at ceridwen.us> writes:
>> >     This is effectively my "feature" flags suggestion from before.
>> >     You flag (new) features as they are used, and refuse to load
>> >     the database if there are used features that you don't
>> >     understand.
>> >
>> > Something to look at adding for 2.6 to get ready for the database
>> > overhaul in 2.8/3.0. It's not in 2.4, and it would need a new "feature"
>> > table to hold the features so it probably shouldn't go in.
>>
>> Luckily the features table is one that doesn't affect the rest of the
>> database, so we could add it in without breaking <=2.4.8; but yes, only
>> versions >= 2.4.9 would know to check it, so it wouldn't necessarily
>> help older versions.
>>
> To avoid confusion:
> You propose to add a features table for the upcoming 2.6 and backport it to
> 2.4.9. So all (stable) versions as of 2.4.9 know how to handle it.
>
> Together with this, I presume we should bump the compat version parameter, so
> that older versions of GnuCash will not attempt to load data files with that
> depend on the features table ? I don't see another way to prevent unintended
> access to newer features by older versions.
>
> Does it have to be a complete feature table by the way ? Or is just adding a
> single number (like the minimum required gnucash version to open the data
> file) sufficient. I don't see how an older version otherwise would know what
> features to check in order to determine if it is still compatible.

In the change I will commit, the the xml backend will use the XML
version number (currently 'gnc-v2') to determine if it can read the
file and if it cannot, it will pop up a message to the user just like
the sql backend does now, and not read the file (prior versions of
gnucash, that is, the existing code that is deployed, will also not
read the file but will give the user a cryptic message). Then, any
time a developer adds anything to the xml that cannot safely be read
by an already deployed gnucash, that xml version number should be
increased (in your case to 'gnc-v2.0.1', for example) when the xml
file is written. This will not be feature specific.
>
> Another question: who will be implementing this ? I don't feel comfortable
> enough in either backend to do this. If it weren't for Alex' example, I would
> have quite some difficulty also to simply add a new data field.
>
> Geert
>


Regards,

Alex