Geert
See comments below: > > ---------- Forwarded message ---------- > From: Geert Janssens <janssens-ge...@telenet.be> > To: gnucash-devel@gnucash.org > Cc: Derek Atkins <warl...@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 <jra...@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@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 > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
