New data field for invoice object

[Derek Atkins]

Hi,

John Ralls <jralls at ceridwen.us> 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?

> I don't remember offhand what distinguishes a bill from an invoice,
> but I think it's which set of (identical) fields in the entry table
> are filled, which is a poor design. I suggest that in the interest of
> better normalization you go ahead and create the type field and
> consider collapsing into a single table the invoice and entry tables
> -- or at least shrink the entry table to a single set of fields
> (instead of the current, identical, i_ and b_ sets) -- the purpose of
> which is determined by the type field.

The main difference is whether the owner is a Vendor or Customer.

> While I'm ranting, another poor design choice that jumps out is
> addresses. The same fields exist twice in the customer table, once in
> the vendor table, and once in the employee table. There should be a
> single address table, and the other tables should have a foreign key
> to its primary.

I have no idea why the database did it this way.  I don't know why there
isn't a GncAddress table with references from Customer, Vendor, and
Employee.

> 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