On 7/20/07, Matt S Trout <[EMAIL PROTECTED]> wrote:
Those of you who do, please bear in mind when responding what anything
involving the creation of assloads of objects will be laughed at and/or
ignored since the intention is SQL::Abstract-level performance.
Along the lines of performance concerns, I suspect even with a focus
on speed that this two-pass AST system is going to slow us down a
little in return for the flexibility it adds. It might be important
to allow for values to specified as (possibly named, as opposed to the
ordering-sensitive ?'s common in SQL) placeholders in both the DWIM
and explicit AST, allowing the DWIM -> explicit -> SQL conversion to
be cached and re-used with different variables, like (and probably in
conjunction with) prepare_cached, but at a higher level.
Then it's just a matter of implementation details like having RS's
cache their converted explicit AST and SQL representations when
executed via some new syntax, like:
sub elsewhere {
$self->{complex_rs} = $some_rs->search({ ... complicated stuff for
the parser here, has bind vars });
}
sub called_many_times {
my $rs = $self->{complex_rs}->execute(foo => $_[0], bar => $_[1]);
while(my $row = $rs->next) { .... }
}
Of course this touches on that whole thing about splitting ResultSets
up into their two functional parts again too (rs as abstract query, rs
as sql cursor)...
-- Brandon
_______________________________________________
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/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
