Geert, > > ---------- Forwarded message ---------- > From: Geert Janssens <[email protected]> > To: [email protected] > Date: Tue, 25 Oct 2011 20:21:20 +0200 > Subject: Re: New data field for invoice object - Follow up > I've been silent for a while on this topic, because I was occupied with other > matters. > > I have followed the whole discussion and the suggestions made on adding a new > data field or kvp. After digesting is for some time, let me post some personal > conclusions for my current case: > > * Clearly GnuCash' ability to deal with different data schema versions can use > some improvements. > > * There were some suggestions that Alex added some code to introduce version > checking in the xml backend similar to what is available in the sql backend. > But I didn't find that code in svn. Perhaps I overlooked, or perhaps this code > was part of the patch for his num_entry field that never got applied. So as > far as I can see there is currently no version checking in the xml backend. >
You are correct that this code was in my patch, that I sent to you, that was never committed. > * So with what we have now, adding a new field is pretty disruptive and I'm > more inclined to go with a kvp. > If your intention is to use the KVP approach, I will extract the version checking part and commit that seperately to trunk and backport it to 2.4. > * The drawback of the kvp is that older versions of GnuCash could open the > data file, don't interpret the kvp and as a result do "bad things" with the > data. > > * I think though will not be that bad. For starters, as Graham already hinted, > if you load a data file with credit notes with an older version of GnuCash, it > will treat them as negative invoices. Payments on such invoice are the main > problem. > > * With the progress I've made so far on the credit notes feature, I believe it > will be relatively easy to backport some business logic to the 2.4 branch to > make that branch sufficiently aware of credit notes to not mess up. If I at > the same time don't backport any user interfaces to this branch, we will have > a GnuCash version that understands credit notes, but doesn't explicitly let > the user handle them. Of course as credit notes are interpreted as negative > invoices, the user could open one via Find invoice. I could add a restriction > there to consider each negative invoice as read-only, so the user won't be > able to edit the credit note in 2.4.x. > > * In the long run, the complete data model will have to be revised. At that > time, the kvp can become a true data field. With that, we will have one big > data incompatibility break. I prefer that over having small breaks all the > time. > > Geert > Regards, Alex _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
