New data field for invoice object - Follow up

[Alex Aycinena]

Geert,

>
> ---------- Forwarded message ----------
> From: Geert Janssens <janssens-geert at telenet.be>
> To: gnucash-devel at gnucash.org
> 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