[Dbix-class] SQL::Builder propaganda review

[Darren Duncan]

Sebastian and others,

I can't think of too much to say about SQL::Builder at the moment, 
but I was asked today on IRC to share my opinion, so here goes.

My first feedback is that the current version 0.03 would be a lot 
easier to evaluate on CPAN, where various mirrors HTMLize it for us. 
I saw a tarball for it at 
http://unf.be/~sili/projects/sqlbuilder/SQL-Builder/ which is a week 
old, plus 0.02 is on CPAN, so I think it would be good for this 0.03 
to go up.

Next, it appears that SQL::Builder has a laudible goal of focusing on 
an aspect of working with SQL and databases that is unique to it.

My impression from Sebastian's email is that it is more PPI like than 
many other solutions, in that it focuses on treating SQL as a 
document which is represented in a finely grained manner, and not 
treating it like code that has meaning.

The moment a module tries to start understanding the *meaning* of 
SQL, it has already crossed over into the realm of doing SQL 
abstraction, and supporting multiple database dialects, and this is 
what most non-phrasebook solutions do, including my own.

By explicitly not trying to be portable, and explicitly supporting 
exactly one SQL dialect at a time as is defined by its user, 
SQL::Builder has the opportunity to support even esoteric and hard to 
abstract features for specific databases, by the fact that it isn't 
coded to explicitly support them at all.

On the other hand, I see that you have followed some "yet another" 
paths by having a large number of classes, each specific to a portion 
of a SQL statement; I don't believe this approach scales as well when 
adding new features as having a more data defined approach does, 
where you have very few actual classes, and most of what you have as 
a class now is a 'type' attribute of a generic class instead.  Of 
course, I'm biased by the latter being how SQL::Routine is built, and 
you're welcome to continue your current path and see how well it 
works longer term.  And you're not the only one to do it the way you 
are.

At the very least, the intent of your module to do all the SQL 
stitching itself (as some other modules also do) and not having user 
code do a pile of joins, is a very good feature to have.  At the end 
of the day, a lot of these modules are to save user code the tedium 
of stitching, and letting people build queries in a more natural way 
than sequentially.

One point of criticism is that, you appear to want to sell your 
solution as being simpler and having less overhead than abstraction 
modules; however, having a large number of component modules as it 
does speaks "large" to me.

I suggest selling your module more on that it helps gather and stitch 
together a SQL concrete syntax tree and saves your application on 
tedious code, and hence errors.  But I wouldn't sell it as being 
smaller and simpler, unless that is advantageous and you can give 
specific examples demonstrating this.

Good day. -- Darren Duncan