New data field for invoice object

[Derek Atkins]

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.

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.

> Regards,
> John Ralls

-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