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

[Derek Atkins]

Geert Janssens <janssens-geert at telenet.be> writes:

> 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.

It's bad because the invoice KVPs were not saved/loaded.

> - 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)

Actually, read is correct.  The way I would implement this would be an
OPTIONAL boolean XML entity, e.g.:

  <gnc:invoice-is-credit-note value="true" />

You only need to emit this entity if you have a credit note.  If an
object is NOT a credit note then you can leave the format as-is (i.e.,
if it's an invoice, do not emit this boolean xml entity).

> - For xml, this happens automatically, because once the new field is used, 
> older versions will bail out on parsing the file.

This should be the case.

> - 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.

Which, IMHO, is okay.

> 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.

Personally, I'm fine with XML and SQL doing slightly different things.

> 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.

If we bump the version number we might as well also add feature flags so
the next time we have this issue we already have something in place that
will let us say that we've added something that older versions don't
need to know about if unused but need to refuse to load if it is 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.

I'm fine with 2.4 gracefully failing to load in the presence of credit
notes.  I don't think 2.4 needs to understand them, just recognize they
exist and tell the user.

> ... 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

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available