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

John Ralls jralls at ceridwen.us
Tue Dec 6 18:01:54 EST 2011


On Dec 6, 2011, at 2:20 PM, Geert Janssens wrote:

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

No, I think that's got it.

If you can't handle credit notes in 2.4 without too much of a change, you could
detect them at load and raise ERR_BACKEND_TOO_NEW, though I admit that's not much of an improvement over failing to load because of an unrecognized element.

Regards,
John Ralls




More information about the gnucash-devel mailing list