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

[Geert Janssens]

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.

Geert