[development] SQL abstraction, was: Do not let postgresql hold back great patches

[Ivan Sergio Borgonovo]

On Mon, 03 Dec 2007 01:52:13 -0500
Darrel O'Pry <dopry at thing.net> wrote:

> adrian rossouw wrote:
> >
> > On 03 Dec 2007, at 6:38 AM, Larry Garfield wrote:
> >
> >>
> >> #3 is what I'm pushing for in the D7 database overhaul, within 
> >> reason.  How to 
> >>
> >> abstract everything without making the syntax insane or the
> >> performance 
> >>
> >> terrible is what I'm currently trying to wrap my head around.
> >> The biggest 
> >>
> >> problem is field type handling, which I want to keep away from
> >> module 
> >>
> >> developers but varies greatly depending on the database.
> >>
> > and the biggest issue here is date / time types.
> >
> > it's fscking crazy how different these are between databases.
> 
> I could have swore that some where I mentioned  creating  query 
> constructs with the syntatical properties of SQL statements and
> mapping them to phrases...

If by query construct you mean a string... as Larry on his website
(somewhere... connection is not that good right now) it is not the
most efficient.
Un-serialised stuff (program logic) -> serialized stuff (sql alike
construct) -> unserialized stuff (sql parser).

What have been done in schema api is more on the spot.

You keep the different part of the query separated and let the DB
specific engine glue them. That way you skip the analysis and the
"transfer" part is a sort of compilation, but generally much easier.

You'd still have to provide a common way to pump custom code directly
in the DB depending on the db_type that's not so ugly as a switch and
that provide a fall-back.

You've some added feature too... since the "compiler" understand a
bit of SQL you could avoid some SQL injection too (even if this as I
suspect is what Larry define "The biggest problem is field type
handling".)

But... this will require a lot of rewriting of modules.
While there is no special logic in building up tables, and you
generally don't do it on the fly, passing objects in spite of strings
is a quite different thing.

As a side note objects may offer some extra caching for stuff like
record count and paging. Something that seems critical in terms of
optimisation across several DB.

> Now that I have my old servers back in hand the idea might be found

the old server looks buys ;)

> at http://darrelopry.darkstyles.doesntexist.com/node/63... While

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it