[Dbix-class] [OT][ANNOUNCE] SQL Generation with SQL::DB

[Matt S Trout]

On Mon, Sep 17, 2007 at 10:22:44AM +0200, Mark Lawrence wrote:
> On Wed Sep 12, 2007 at 05:23:28PM +0100, Matt S Trout wrote:
> > On Thu, Sep 06, 2007 at 02:25:44PM +0200, Mark Lawrence wrote:
> > > 
> > > The second reason is extensibility. Take for example
> > > SQL::Abstract::select (to be fair, the other query types are ok):
> > > 
> > >   select($table, \@fields, \%where, \@order)
> > > 
> > > With such fixed position fields how can we extend this to handle
> > > "FROM t1 AS n1,t2 AS n2" statements? Does the caller have to keep track
> > > themselves of the table aliases? How does one handle multiple JOINs
> > > with optional ON/USING conditions?
> > 
> > If you don't know how that works, you didn't read the DBIx::Class docs.
> 
> What does DBIx::Class have to do with this? I'm talking about
> SQL::Abstract, and the only mention of further reading in the SQLA
> documentation is DBIx::Abstract, which also doesn't appear to enable
> multiple INNER/OUTER LEFT|RIGHT JOIN statements.
> 
> You've got some pretty high expectations for newcomers to SQLA if
> they have to get all the way to DBIx::Class::Manual::Joining (or
> maybe somewhere else I haven't been to yet), where one finds out
> queries generated anyway don't even use JOIN. But that is all beside
> my point.

No.

There's substantial SQL::Abstract extension work in DBIC that isn't on
CPAN yet because we've decided to step back and try and produce something
more general rather than just keep hacking.
 
> My point is that having to force more levels of $table and \@field
> values into the %where hash is not a clean extension to the API.
> The 'hidden' definitions inside %where are second class citizens.
> They are not visible at the time of the select(), and the implication
> is that tables/fields are inside a WHERE (...) statement which is
> misleading.

The first element to select() can't currently be a hashref.

Ergo, we can extend select by providing an API that takes a hashref.

> A four field fixed-position function prototype for select() simply does
> not allow for what is possible with SQL. But this you know already.

See above for why that's irrelevant.

> Ok, badly phrased. My backcompat statement was meant to imply that
> the internals of SQLA would have to be changed so much that the effort
> would be far greater than the cost of starting from scratch. And that
> was in response to your question about why not send patches. When creating
> a new API it rarely makes sense to start with an old codebase (in the
> same way that DBIC 0.01 wasn't a patch against CDBI).

Class::DBI::Sweet was.

And then DBIC was written rather more carefully and I've refactored the core
compatibly several times now. The SQL::Abstract codebase isn't so bad either.

My "rewrite" threshold is pretty high these days, I've found if you're
careful and know how to shim the worst mistakes of an old API the only real
reason to scratch rewrite working code is as a prototyping exercise before
you refactor the real thing.

> For the record, I think the DBIx::Class backcompat efforts have been
> great, which I took advantage of when I moved from CDBI to DBIC
> (just before I moved from DBIC to Tangram, just after I toyed around
> with RDBO, long after I stopped using hand-coded classes, ... ;-)

Kinda funny really, given Sam Vilain long since moved from Tangram to DBIC
and part of the reason for the SQL::DB like API (except without the |& suck)
plans we have is discussions from he and I about how to make DBIC function
as a better Tangram as well as a better Class::DBI.
 
-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/