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 <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. > 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
