New data field for invoice object

John Ralls jralls at
Mon Oct 10 12:56:27 EDT 2011

On Oct 10, 2011, at 9:05 AM, Derek Atkins wrote:

> Hi,
> John Ralls <jralls at> writes:
>> Geert,
>> The way you'd implement an optional type field in an RDB is to create
>> a new table for it with two fields, a key (which would be the invoice
>> GUID) and the type, and the code for handling that table would have to
>> examine the database version and not use it if it's an older
>> version. Similarly, your new credit note code would have to check with
>> the backend to see if it's OK to create the note, because an older
>> version of Gnucash will do the wrong thing with the data. This is a
>> Bad Idea. We're tying ourselves in knots worshipping backward
>> compatibility. The current data model is not a good design, but we
>> can't fix it if we have to stay bidirectionally compatible with older
>> versions.
> This seems particularly complicated to me.  Note that I'm not a DB
> enginner, but why can't you just add a new boolean column to the Invoice
> table that has a default value of 'false'?  If an older version of
> gnucash writes into this table the column would take the default value,
> which is fine because the older version wouldn't know how to write a
> credit note anyways.  The question is how to signal that the credit note
> feature is being used?
> Why can't this be done in the same way that ext2/ext3 works?  The base
> underlying system is completely compatible.  The main difference between
> ext2 and ext3 is the journal, but there are other features as well.  If
> you're not using any of those features then you can mount an ext3
> filesystem as ext2!  It works great.  But if any of the ext3-only
> features are in use then ext2 will complain.
> Why can't we do that here?  Have a 'features' table that has a list of
> all the features that are used in the database.  If the current version
> of gnucash does not understand one of the used features then it tells
> the user that they need to upgrade to a newer version of gnucash because
> it doesn't understand database feature X.  Then when the credit note
> feature is USED, the credit-note feature gets set blocking older
> versions.  However, if there are no credit notes in the DB, then an
> older version can still read and write the database (because the feature
> can have default values).
> Am I missing something here?
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.

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.

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

John Ralls

More information about the gnucash-devel mailing list