[Dbix-class] SQL::Builder propaganda review

Sebastian buddhahead at gmail.com
Mon Oct 31 04:29:53 CET 2005


Very helpful, thanks. I'll take these points into consideration during
further development.

> 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.

A large number of modules seems to
complicate things from a birds-eye view, but I think when it comes
down to development, each component is granular and separated
from the rest, so modifications and extensions should be easy to
do. Development has been a little easier because of this trait, so
far anyway. When I have build errors, it can usually be tracked
down to a single place in my code, and that code is mostly
orthogonal so its very clear and easy to understand.

I also think that if I'm able to write a clean and intelligent
interfaces for the modules and glue them together nicely, complexity
will seemingly decreased. We'll see how this goes, though.
If this proves to be problematic I'll be glad to re-evaluate the approach.

> 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.

I will definitely take this into consideration for my next release (coming soon)


Thanks for the feedback,

Sebastian

On 10/30/05, Darren Duncan <darren at darrenduncan.net> wrote:
> 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
>
> _______________________________________________
> List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
>


--



-------------
buddhahead at gmail.com



More information about the Dbix-class mailing list