Re: Checklist for 1.3

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

Jeff wrote:
> Can you elaborate on the planned implementation of the integrity controls? I'd
> like to read up on the parts of Postgresql involved (and deemed most
> appropriate by the core developers): Declaritive Referential Integrity (DRI),
> triggers, functions or stored procedures instead of triggers, etc.

Data integrity controls include declared foreign keys, check
constraints, and triggers where these are not sufficient.  Stored
procedures are used as an additional API layer to simplify add-on
module development.  I don't foresee many custom triggers but they
could be added as necessary.


On 3/3/07, Jeff Kowalczyk <..hidden..> wrote:

> Are there any postgresql features that would allow a connection to the same
> database but without the in-database (but non-DRI) integrity/model features?

Not sure I understand what you are including and what you are not.

> E.g. if you were crazy enough, you could take on all SP responsibility/control
> back in your language's ORM. I don't know enough about postgresql schemas to
> guess whether they can offer per-schema trigger and function/SP definitions for
> the same underlying table instances.

Not sure why you would want to do it that way, but it is possible.  I
think we expect a stable physical schema at some point.

A more likely scenario is that you could add triggers to a stable
schema in order to replicate data between LSMB  and another
application running off the same database but in a different schema.
Opengroupware and interchange come to mind.
> My thinking is that someday, presupposing a complete test suite has built up
> around the data model, someone might like to work with their favorite ORM on a
> 100% compatible implementation of some particular module or the entire
> LedgerSMB backend. Pass the same tests, but with pure language+ORM code.

Sure, but I think that when you start multiplying where code is
written and stored, you will get bugs.  As long as the ORM is prepared
to use our catalogs for function names and arguments, they may want to
just go through the stored procedures.  This is the major reason for
putting these in the db-- i.e. if someone wants to use JasperReports,
you have the entire object model available through the SQL interface.
> It would be great to see a detailed unit/functional/integration test suite
> eventually become the real 'product' of LedgerSMB, and LedgerSMB the
> application as we know it, was simply the reference implementation, with the
> vast majority of the community using and maintaining it.

That is sort of the idea.
> Given the background of the core developers, we can be quite comfortable with
> the stated direction of LedgerSMB's refactoring (90% stored procedures, 10%
> perl UI as the reference implementation).
The key aspect is not what percentage of the code is in stored
procedures but rather what code is there.  In this case, it is "data
logic" or the M in MVC.  This will also be self-documenting in the
database.  So it should be possible for someone to write an ORM that
simply pulls that data from the db for the ORM in whatever language
they want.
>
Best Wishes,
Chris Travers