Architectural enhancements

[Ged Wed]

I just found dbslayer. Its a really smart idea.

Database Abstraction

-------------------------------

Because its an abstraction layer and Hibernate and NHibernate (the .NET port) seems to be the perfect mechanism to provide database agnostic abstraction.
This is dramatically easy to do with Hibernate because the actual over the wire SQL is available from the events architecture of Hibernate.

i have not read deeply into how the SQL is "translated" into JSON, but the principle i am encouraging here makes allot of sense.

What do people think ? 


Read / Write Scaling

-----------

As is understand it one of the tenants of DBSlayer is to get around the issue of the connection limits to a DB.

TO me an even better enhancement is to allow it to separate out Read only Data bases from Read/Write Databases. 
This is a very common technique to scale out your DB servers, and well supported by almost all databases.

Would it not make sense as part of the Database Abstraction to include this principle in the Architecture ?
i have already done this with Hibernate and NHibernate, and is very easy to do because the SQL produced can be simply parsed just before it is executed against the DB to decide which Database the Call should be send to.

Regards

Ged

[derekg]

right now separating out reads from writes is done via convention and
the application level. parsing sql is effective but fails in cases of
stored procs and i hate giving the sense of magic. i am interested in
somehow improving this though - as long as things are explicit and
understandable.

d

[Michael L Welles]

Derek:

Would there be any value to in a worse-is-better sort of approach?

What if the client could state their intent by adding optionial 'type'
parameter in the incoming JSON request? If the value was 'read-
only', dbslayer could route it to its pool of slave db connections,
otherwise pass it along to the master.

It'd push the decision making down to the driver API layer. My hunch
would be there'd be less pain in implimenting the decision making
there, and I could see that it might help avoid the headache of
managing two seperate database connections in those applications that
would like to be well behaived, and mostly want to read, but sometimes
have to write.

[Jacob Harris]

Hello,

I think that's a useful idea (I could support it pretty quickly in the
ActiveRecord adapter for instance). But I'd be willing to hear out
discussion on the matter.

Jacob

[Michael Welles]

Yeah, it'd seem to be most useful in an ORM context, or some other
situation where the SQL is generated. It doesn't spare you from the
problem of unanticipated writes resulting from stored procs or
triggers, but those are probably less common in environments using
some sort of ORM framework.

In the case of the stored procedures, some sort of naming convention
on those which perform writes might help for smarter decision making
on whether to add the 'read-only' flag to an outgoing request. But
that kind of 'magic optimization', besides being kinda an ugly hack,
would be solidly environment / application specific and deserves to be
pushed as far down the stack to the client side as possible.

[Derek Gottfrid]

I could go for that. Would be a pretty small change to the existing code.
d

On Wed, Jul 8, 2009 at 2:56 PM, Michael L Welles <mlwe...@gmail.com> wrote:

[Michael L Welles]

I'm starting paternity leave tomorrow, so I've got some time,  and it'd be a relief to hack on something not work-related.

If theres no objections, I'll check out the code tonight and take a whack at it over the next few days. 

Anything in particular I should keep in mind while I do?   

 - Ohio Pants