[Dbix-class] SQLA refactor: proposal

[Darren Duncan]

At 3:42 PM +0000 11/26/07, Matt S Trout wrote:
>I'd hope that we can also look at sharing much of the MuldisD -> SQL code
>with your SQL DBMS Muldis::DB backend code later, but that's a 'would be
>nice' not a primary target.

One design decision that is central to my own Muldis D 
implementations is that I fundamentally generate Perl code (rather 
than SQL), in the form of Perl closures with named parameters, from 
Muldis D routines at 'prepare' time, and then invoke the Perl 
closures with named parameters at 'execute' time.  If the Muldis D 
implementation is over a SQL database, then said generated Perl code 
is what actually invokes DBI and/or DBI is invoked (for 'prepare') 
while generating the Perl code, or whatever this detail is 
implementation dependent, but the SQL is embedded in the Perl.  The 
advantage of this is that one Muldis D query can be turned by the 
generator into Multiple SQL queries if necessary (because SQL is less 
expressive than Muldis D in general), and the generated Perl code 
will do appropriate pre/post/inter-SQL-query or in/out value 
processing, so users of the generated code don't have to, and can 
invoke it more like a Perl routine.  I highly recommend this design 
approach to the SQL::Abstract rebuild on the generator side if you 
want to have the fewest useability issues, as well as a better chance 
of integratability with my implementations.  I'm also sure it can be 
made no slower than what you have now if good judgements are made for 
when particular things are done and what steps are cached for reuse. 
-- Darren Duncan