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 _______________________________________________ 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/[email protected]/
