New data field for invoice object

[John Ralls]

On Oct 10, 2011, at 10:13 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>> Your ext2/ext3 example is a bit simplistic: Ext3 adds a single
>> (optional) feature, journalling, which doesn't affect any of the other
>> data structures. It just reads and writes a hidden file. No file, no
>> journal, no problem (unless, of course, you need to recover from a
>> crash ;-) ). Not the case here.
> 
> Well, in this case we're also adding an additional optional feature.  If
> you don't use credit notes then you should still be able to use the
> data.
> 
>> What you're missing is that the boolean field that you propose to add
>> is what distinguishes a credit notice from a regular invoice. If the
>> db (or xml file) is opened by an older version of Gnucash, it won't be
>> able to tell the difference, and will treat it as an invoice
>> regardless. That would be bad, so it must be prevented.
> 
> I'm not missing that.  The point is that if the boolean field is false
> then the data *is* exactly the same as it was before so it should be
> completely readable (and writable) as it was before.  Only if there are
> any credit notes at all should the database become inaccessible.
> 
>> The features table is an interesting idea, though it could get pretty
>> cumbersome pretty quickly... and in this case it would have to do the
>> same thing: Tell the user that he can't load his db, because it might
>> have data that would corrupt his books in the older version. 
> 
> It might become a little cumbersome after a while, but it can always get
> refreshed after some major database version upgrade.  But it's not the
> same thing as you are proposing.  The point of my proposal is to allow
> the newer database to continue to be used by an older version until the
> new features of the newer version are actually used.  It would only tell
> the user that the data can't be loaded *IFF* there are credit notes in
> the database.  If there are no credit notes then the database should
> still be usable.
> 
>>               In any
>> case, it doesn't at present exist, so it would have to be
>> introduced... and any version of Gnucash *before* that would still
>> have to be prevented from loading the db, so that it doesn't corrupt
>> the book by misinterpreting credit notes as invoices. Fortunately,
>> *that* code is already in Gnucash 2.4. There's still the problem of
>> loading an XML file with credit notes into 2.4.6 or earlier, since the
>> XML backend didn't have versioning and blocking until Alex added it in
>> 2.4.7.
> 
> I agree that it doesn't exist, but it can be added to 2.4.8.  And we can
> upgrade the database version number so that 2.4.7 and earlier would fail
> to load it.

So you're asking for every code change that touches the way data are stored to set a flag in a feature table that it's actually committed such a change, and for each backend to have a hard-coded list of the features it knows about, and to check to see if there are any features in the stored feature list that don't match that, and to see if it's been used, and only then to refuse to load the database/XML file? Seems incredibly brittle, worse even than the version blocker.

And this is to support all the users who routinely use multiple copies of Gnucash and can't bring themselves to upgrade more than one of them at a time? Do you have any evidence that such users exist? What other programs do you know of that allow old versions to read upgraded datasets?

> 
> What Alex added IIRC was code to make the load error clearer to the
> user.  The XML backend would ALWAYS panic if it found an unknown XML
> tag.  Go ahead and try it yourself, add a random unknown tag to an XML
> data type and see what happens when you try to load it.  You should get
> a parsing error and gnucash will fail to load the file.  It just wasn't
> very user-friendly in how it did it.

OIC. I didn't realize the XML parser did any validation. But it chokes only on elements, tags it accepts.

Regards,
John Ralls