[Dbix-class] Explicit ASTs (ping nate)

John Siracusa siracusa at mindspring.com
Tue Sep 5 03:12:13 CEST 2006


I've been fiddling with some design ideas in this area for some time.  I'm
just as happy to have someone else do it for me, but there's one feature
that I'm kind of married to that I haven't seen mentioned in this thread.
I'd like to be able to tie each thing selected to a data type and source.
For example:

  SELECT MIN(a.start), b.type FROM a, b WHERE a.b_id = b.id AND start < ?

Here I'd want the abstract form to know things like this:

* a.start is a TIMESTAMP column.
* MIN() will return a TIMESTAMP.
* b.type is a VARCHAR(16)
* "start" is the same column as a.start

and so on.  I want this info so I can bind the exec args correctly (doing
inflate/deflate as needed to coerce values for the target db) and so I can
dress up the results in the same way.

I'm happy to write adapters from some generic metadata hooks to my own
metadata classes, but the hooks have to be there.  Minimally, the abstract
form should keep track of which data is coming from which source (table,
subselect, literal, whatever).

If necessary, something can walk the structure later and hook up the
appropriate metadata for each data source, selected value, and bind param.
But ideally, this would be done during the construction process through some
callbacks, rather than in a post-processing step.  Here's a sort of mental
walk-thru of the query above as it might be built:

ooO FROM a.  Looks like a table.  Anyone know anything about table a?
(callback).  How about table b?  (callback)  SELECT MIN(...).  Any info on
MIN()?  (callback).  a.start.  Table a has a column named "start."  This
looks like a table-prefixed column from table a.  It's of type TIMESTAMP.
MIN() passes that type through.  b.type... Ooo

etc. etc.  (Obviously I'm not talking about parsing the SQL; I'm just using
the SQL as a guide through the process.)  IOW, parsing the "whatever" fancy
syntax and building the AST would be filled with questions about the stuff
being selected from, bound to, and so on.  The answers to those questions
would help mark-up and cross-link the "chunks" of the query so that I can
ask interesting questions like, "How many columns from table b appear in the
HAVING clause outside of a function call?"  That's the kind of smarts I'm
looking for in an "intermediate form" (the term I prefer over AST) for SQL
statements.

-John





More information about the Dbix-class mailing list