Re: Checklist for 1.3

[Josh Berkus <..hidden..>]

JD, Chris,

> The long and short of it is this. Core believes that data integrity
> belongs with your data,

Or, in less abstract terms, we expect that people will want to create plug-ins 
and interoperability modules for LedgerSMB with other software.  The best way 
to make sure that extensions of LedgerSMB cannot mess up the base financial 
data is to create a bulletproof data API for them to plug into instead of the 
base tables.

While such an API could be created in middleware, creating a middleware API 
which would be programming-language agnostic and sufficiently robust and 
secure would be significantly greater effort (as in 3x to 10x) than doing it 
inside the database.  Especially given our pool of expertise, which includes 
several PostgreSQL experts.

> which means we will be 
> implementing data type constraints, custom domains, RI, triggers, rules
> and any other method required (including functional check constraints)
> to insure that the data of ledgersmb is impeccable.

I've done this with other financial databases.   Generally I end up 
implementing a full abstraction layer in the database, consisting of numerous 
views and functions replacing direct table access.  I would tend to lean 
against triggers/rules on base tables, except for data auditing, as they are 
difficult to manage from a development perspective and can easily have 
unintended effects.  Views and data-push functions, or pseudo-tables, allow 
front-loading of business rules in a way which can be easily isolated to 
specific data regions.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco