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

[Alex Aycinena]

Geert


See comments below:
>
> ---------- Forwarded message ----------
> From: Geert Janssens <janssens-geert at telenet.be>
> To: gnucash-devel at gnucash.org
> Cc: Derek Atkins <warlord at mit.edu>
> Date: Tue, 06 Dec 2011 23:20:57 +0100
> Subject: Re: r21577 - gnucash/trunk/src/backend/xml - Fix xml backend to load and save invoice kvp values.
> Op dinsdag 6 december 2011 10:08:58 schreef John Ralls:
>> On Dec 6, 2011, at 8:56 AM, Derek Atkins wrote:
>> > John Ralls <jralls at ceridwen.us> writes:
>> >> 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 completely true.  The GnuCash XML backend is hand-coded, and
>> > historically it will complain if it sees an element that it does not
>> > know about.  So no, it is not validated, but it is rather rigid in its
>> > reading (at least historically).  Feel free to try it.  :)
>> >
>> > It might not error out, per se, but it will cause load failures.
>>
>> Sorry, I meant the other way around: It doesn't complain if an element is
>> missing unless there's code that looks for that element, nor does it save
>> elements that it doesn't use. That's what would allow almost all users (the
>> ones who have no interest in credit notes) of the XML backend to still be
>> able to move from one version to another without problems.
>> >> 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.
>> >
>> > I agree, but we want to make the change so that you can still use 2.6
>> > w/o using the new feature and still load the data file into 2.4.
>>
>> Roger.
>>
>> Regards,
>> John Ralls
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> So, let me summarize what has been discussed so far:
> - KVP is bad in this case because a clear risk if data loss when opened in
> older files.
> - So I will have to add a new field.
> - Older versions should be prevented from reading files in the new data format
> (actually writing, but we don't distinguish this yet)
> - For xml, this happens automatically, because once the new field is used,
> older versions will bail out on parsing the file.
> - For sql, the only mechanism we have so far is to bump the compatibility
> version. The disadvantage of this is that once this compat version is bumped,
> older versions of GnuCash won't be able to read the sql data regardless of
> whether the new feature is used or not. The same mechanism as with xml data
> doesn't work here.
>
> To get to a working solution with what we have now, I propose these actions:
> 1. Ask Alex to commit his versioning code for xml that he wrote as part of his
> work on the customized number field. This would at least align the data
> protection mechanism for the xml and sql backends, so we can work out a common
> solution for both. This should be backported to 2.4 as well in my opinion.

I will plan on doing this in the next few days.

Regards,

Alex

> 2. Add the new data field and bump the compatibility version. This will
> prevent data loss in versions unaware of the credit note field. At the same
> time it will block older versions from opening the newer data files,
> regardless of whether or not the credit note feature is actually used.
> 3. Add code to the 2.4 series to deal with the presence of credit notes
> gracefully without actually exposing the complete functionality. This may turn
> out to be too tricky, in which case, no backward compatibility will be
> available in 2.4. The business logic assumptions regarding invoices/bills are
> pretty subtle and in many areas. There is a real chance that in order to
> support the credit note data field gracefully in 2.4 I may end up backporting
> of most of my non-GUI changes. I'm not sure that would be justifiable for a
> stable release.
> ... Did I forget something ?
>
> This is not the optimal solution, but the best I can come up with in my
> available time and with the state of the backends as they are now.
>
> Geert
>