Re: Checklist for 1.3

[Jeff Kowalczyk <..hidden..>]

--- Chris Travers <..hidden..> wrote:
> 1)  Cross-development-environment data model.  The same data model can
> be accessed from Java, Groovy, Python, Perl, PHP, VB6, .Net, or
> whatever you want to use.  It will be entirely encapsulated in the
> database (rather than having the data model encapsulate the database).
>  We will use some basic glue to re-encapsulate in Perl but this will
> be thin.  Other envelopes could be implemented easily without too much
> work in other languages. (... 2.) the ORM works almost in reverse.

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

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.

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.

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


 
____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/