Re: Call for testing experimental patch

["Chris Travers" <..hidden..>]

Just so we are clear as to why we are proceeding in the current direction. :-)

A lot of the "new" features are really merging existing code into the
current application or things that people are currently sponsoring.
Most of these are areas where the existing functionality is simply not
sufficient for many customers and where merging this code is easier
before rather than after the database schema changes.  Getting these
changes merged is a high priority because it allows these customers to
move to something better than SQL-Ledger.

Secondly, the unique id patch actually does complete acc_trans's
foreign key at least for now.  In this case acc_trans.trans_id
references id_tracker.id and the other id fields are basically both
primary and foreign keys for their defined tables.

Getting the schema into real shape litterally means rewriting the
entire application from scratch.  We discussed this but decided that
it would be better for our customers (who are/were using SQL-Ledger)
if we did this incrimentally.  The id_tracker patch goes a *long* way
towards restoring relational integrity to the application and while it
is not perfect nor the best long-term answer from a maintainability
standpoint, it does a nice and elegant job of fixing the problem for
now.  In the next few releases, I think the db will be undergoing a
pretty major set of changes.

Consider:
1)  SQL-Ledger's db schema allows transactions to be posted where the
database doesn't know where the money went (acc_trans.chart_id IS
NULL).  And the application will sometimes do this under certain
circumstances.  We have already fixed this.

2)  SQL-Ledger will let you ship so something to an unknown location
(shipto.address or the equiv. field IS NULL). And the application
happily lets you do this.  We have not fixed this one yet because the
problem is deeper than just the db schema.

3)  SQL-Ledger will under certain circumstances get its transactions
confused and munge them together.  This is fixed by this patch.

So there you have it-- an accounting program that might not know where
your money or your merchandise went.

I also think that there was a valid fear on the part of many of us
that if we rewrote from scratch, we would be here until well after
HURD was released trying to get something up.

One of my top priorities in the next release is going to be ensuring
that the customer/vendor table unification happens and that we revise
how shipto's work so that it is really normalized.  Also I want to
start revising the handling of ship-to's so that we can actually have
NOT NULL constraints where they make sense (such as the address
field).

Hope that this make some sense.

Best Wishes,
Chris Travers