[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal for 2.0: SODA 2.0
- Subject: Re: Proposal for 2.0: SODA 2.0
- From: Chris Travers <..hidden..>
- Date: Mon, 8 Mar 2010 10:04:47 -0800
On Mon, Mar 8, 2010 at 8:21 AM, Adam Thompson <..hidden..> wrote:
> I'm wondering why the push to move so much functionality into the DB instead of using an ORM, which seems to be where you're headed anyway?
> Or, to rephrase that: if you don't want an ORM in the Perl framework, why are you trying to build one in the DB?
This is less like an ORM and more like "web services" in the sense of
discoverable interfaces that third party apps can use for easy
integration.
> I'm perfectly OK dealing with relational data. In fact, one of the things that's attractive about LSMB is the RDBMS back-end. With security implemented on a table and column level, I can use whatever report generator I want to build custom reports. Making me access everything through stored procedures eliminates any value LSMB has over other accounting systems... at least for me.
Well, you wouldn't HAVE to access everything through stored
procedures. Certain things probably would be done only through
stored procs (posting GL transactions, for example), but probably not
ad-hoc reporting (our standard reports would, but that's another
matter).
> If I have to connect as a fully-privileged user, I guess I can, but doing an end-run around the app is something I associate with Inuit products, not LSMB.
What I would like to see is a set of "layers" for proper integration.
These include:
1) A stable, understandable db schema (primarily for reading data,
but also for writing some types of data)
2) Discoverable stored procedure interface
3) Application object models
4) Web API's.
None of these are where they need to be at the moment :-)
Best Wishes,
Chris Travers