[Dbix-class] retrieve_from_sql

[Matt S Trout]

On Mon, Aug 01, 2005 at 11:43:20AM +0200, Emanuele Zeppieri wrote:
> > Does anybody use this? More importantly, is anybody using it 
> > out of choice
> > or is it purely being used to get round Class::DBI (or 
> > whatever ORM) having
> > insufficient flexibility to let you construct the query in an asbtract
> > fashion?
> > 
> > It's part of the Class::DBI API so we need to support it in 
> > the compat layer
> > at least, but if we're going to abstract away the database 
> > layer entirely
> > (which is necessary for e.g. Rosetta, let alone something like an LDAP
> > backend) I think we should probably only support abstract 
> > formats in core,
> > primarily SQL::Abstract style as currently and perhaps 
> > Tangram style later.
> 
> IMO entirely abstracting away the database layer is *NOT* a good idea at
> all.

No? If you don't do that, how do you support storage in LDAP? Storage in an
XML db?

In any case, the straight DBI backend for DBIx::Class will of course continue
to allow this; what I'm suggesting here is simply making it clear that this
is not a method that will work perfectly for *all* backends and wondering what
we do about it.

I suspect we can probably write an SQL de-parser that will convert at least
moderately complex expressions back into whatever abstract syntax tree we
end up making the standard, but that doesn't seem to me to be something
people should expect to be 100% reliable.

> Nor SQL::Abstract can satisfy any need about SQL queries: it can become
> extremely convoluted for complex queries.

Our current implementation of SQL::Abstract syntax, maybe not; there's no
reason we can't extend it - I ended up ripping the code out the original
module to do some cleanup and changes so the code is in the dbic tree.

Also, I'm not sure it gets that convoluted if you modularise your query
assembly (which DBIx::Class will be helping you with more than a little :).

Can you provide me with a concrete example of where SQL::Abstract is less
legible than writing the SQL yourself? Hard use cases are always welcome :)

> Leave the user the opportunity to resort to raw SQL if she/he wants,
> please.

The opportunity where the storage engine supports it, yes. The guarantee that
every storage engine will I don't want to make because it's IMO a rather heavy
restriction to what can be achieved.

-- 
     Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.