[Dbix-class] Explicit ASTs (ping nate)

[Nate Wiger]

Matt S Trout wrote:
> I was thinking more
> 
> $s->op_and(
>    $s->op_eq(...),
>    ...
> )

Nothing wrong with that, but then again SQL doesn't have overlaps itself 
(AFAIK), so I think it's probably not needed technically.

>> would become
>>
>>     $s->count('*')
> 
> so this would check for the existence of the func_specific_count method and 
> then call
> 
> $s->func_specific_count('*')
> 
> or
> 
> $s->func_generic('count', '*')
> 
> as appropriate

It could, or I was thinking it would just be a subclass thing, and use 
SUPER:: (or NEXT::). Kinda like Catalyst controllers and 
prepare()/finalize().

> I see the $s in the first couple examples that's processing the explicit AST 
> as something like SQL::Abstract::Generator::Generic (or ::MySQL or ::Oracle or 
> etc.) and the $s in the immediately above example as SQL::Abstract::Query or 
> something.

I think that's fine, although technically there's probably no reason 
they need to be different (same ops and requirements). We could have an 
"inflate_ast" and "deflate_ast" (or whatever) that just parsed the AST 
and called methods appropriately.

But revisiting the AST idea, how do you see it being generated? Even 
though it's an interim rep, it still needs to be acted on. If the user 
is just going to call SQL::A::Whatever methods, then it becomes an issue 
of whether a formal/exposed AST buys us a big benefit, or whether just 
building a big $self->{query} that we know about internally is sufficient.

Maybe I'm missing the point and we're talking about the same thing.

> And if the $s in these examples were to build up said AST internally, it would 
> then become trivial for $s->render to pass it on to an appropriate generator.
> 
> Really quite like your syntax sketch there as a user-level API, although I 
> think I still prefer resultset's pure-functional approach.

Could you clarify this a bit? I must admit I'm not super-familiar with 
the internals of resultset...

> One thing that I am sure of is that the final generator should be 
> pure-functional, no state - i.e. "my $sql = $gen->generate($ast)" - that way 
> the generator can cache SQL fragments and even entire queries it's built, and 
> we don't have to worry about selective deep copying and stuff (which is always 
> a source of performance and weird-bug issues IME)

Yup, sounds good.

> What do you think of my comments above, would you be interested in 
> SQL::Abstract being moved in this direction as part of a larger effort?

Definitely. We'll definitely need more than one person working on 
something like this. Once we decide on the "big picture", putting it in 
an appropriate SQL::A 2.x svn repository with a couple hands sounds good.

-Nate