[Dbix-class] Re : Explicit ASTs (ping nate)

[David E. Wheeler]

On Sep 5, 2006, at 06:47, Dami Laurent (PJ) wrote:

> Sounds like a very complex task, since SQL is so big, and has so many
> extensions. The risk then is that the "DWIM AST" will evolve to also
> become more complex (and difficult for users to understand), and the
> inner complexity of the ORM layer will augment to become more like a
> DBMS in itself -- in both cases, the goal of ORM as a middleware
> between Perl and DBMS may be lost.

The AST is mostly for machines to handle, not for developers, so this  
shouldn't be much of an issue. Of course, sometimes a developer is  
going to want to do something really complex that the DWIM interface  
doesn't support, and then she might need to use the AST. Or she can  
perhaps use the support for raw SQL supported by some ORMs.

> An explicit AST is interesting if we want to perform operations on the
> tree ... but if the only operation is to generate SQL, I don't really
> see the point : chunks of strings should be good enough, passed
> directly from the DWIM API to the SQL layer. For example,
> we can already pass a string "COUNT(DISTINCT foo) AS n_foo" to
> SQL::Abstract, and get back rows with a $row->{n_foo} value : what
> more could be done if we had a more structured syntax tree ?

Well, different back ends might do different things with an AST.  
Furthermore, I personally would like to see it get used for non- 
database applications, as well. See LINQ.

> The DWIM API should be very close to SQL anyway, because that's what
> programmers learned and understand. Generating portable SQL is a  
> choice
> of the programmer : sometimes you really want to use proprietary SQL
> extensions of your DBMS, and then you don't want the ORM to be in the
> way. So I think SQL::Abstract does a very good and clever job of
> balancing
> between flexibility, ease of use, and added power, and for helping
> to separate between prepared statements and bound values.

I think that the DWIM layer should be Perl, not SQL. But that's just  
my POV. I doubt that SQL::Abstract's existing DWIM layer will go away…

> So in conclusion I think it may be more rewarding to work on improving
> the DWIM API than to introduce an intermediate AST. Now we have to
> see which proposals could be good enough to be acceptee by Nate Wiger
> for inclusion into SQL::Abstract.

Well, part of the idea of the AST is so that there is compatibility  
between ORMs and DWIM layers. So then you can plug the DWIM layer  
that works for you into whatever ORM you're using, and it'll just work.

Best,

David