Re: Proposal for 2.0: SODA 2.0

[Luke <..hidden..>]

On Mon, 8 Mar 2010, Adam Thompson 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? 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. 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.

Since I find myself agreeing with this to a certain extent, I will chime 
in on something I would have otherwise remained out of.

First of all, I will say that I am not clear on the programming for what 
you are doing--have never worked with PSQL stored procedures, and don't 
know how certain of the other language elements fit into this.

That said, it looks like what you just explained is an order of DB 
obscurity beyond what has been done to date.  What I mean by that, is that 
the interface is getting further and further away from raw table access, 
and in this case specifically is getting quite far away from it.

I understand your reasoning for moving as much as possible into the 
database.  I agreed with it in the beginning as a reaction to SL's 
codebase, even though I have never been very comfortable with it, but I am 
starting to wonder.

We have turned the database from a device for storing and organizing the 
storage and retrieval of information, into a device for processing that 
information in ways which are less and less apparent.  In other words, it 
has been made into a blackbox.
If that is not a description of an ORM, then what is?

For a commercial app with a true API, I probably wouldn't have a problem 
with this idea.  However for an app in which you intend people to be 
writing their own frontends, extensions, interfaces, etc., and in which 
you intend those extensions and such to interact with the database, is this 
wise?

I could see it, maybe, if all database interactivity was handled through 
an API.  In that case you're not talking about database access any more, 
but instead programatic access through an interface which requires no 
direct knowledge of the storage backend, and in fact demands that one 
never interacts directly with that backend.  But that's not what's 
happening here.  The way I understand it, these procedures are obscuring 
the database, from within the database.  So you end up with something of a 
hybrid condition.

That just seems...undesirable.

Now, given my disclaimers above, I recognize that I could be barking up 
the wrong tree, and if so I apologize for wasting your time with this. 
However Adam's comments reinforced what I had started thinking while 
reading your original message--that being that "this strikes me as a 
level of complexity and obscurity too far.".

Regards,

Luke