[Dbix-class] Explicit ASTs (ping nate)

[David E. Wheeler]

On Sep 4, 2006, at 18:12, John Siracusa wrote:

> 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 agree. I think that this is implementation-specific, though.  
Object::Relation, for example, always knows the data type of an  
object attribute, because it can ask Class::Meta for it. It doesn't  
yet support aggregates, though.

> 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).

Yes, it will.

> 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

Right, this is what the metamodel stuff is really good for.

> 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.

Yes, absolutely. The more that can be known, the better.

> 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.

Yes, I think you can ask that of the AST by parsing it. :-)  
("Intermediate Representation", or "IR" is the term Object::Relation  
uses, but it's all the same.)

Best,

David