[Dbix-class] Refactoring Tangram::Expr and Tangram::Relational::Engine - looking for a SQL AST module

[Sam Vilain]

Matt S. Trout and I discussed requirements for an extension to SQL::Abstract
and/or a new module along similar lines that could serve as a base for the
SQL generation performed by Tangram and DBIx::Class.

We came up with some initial functional requirements and summarising our
discussion; hopefully from this we can build some rough test cases to aid
selection of a module or extending an existing module to meet the requirements,
or maybe even re-inventing this wheel yet again.

15:59 < mugwump> 1. I think we both agree that it needs to be a lightweight,
                  "pure" SQL AST module
15:59 < mst> yes
15:59 < mugwump> 2. Tangram::Expr and DBIx::Class will both build these objects
                  internally
15:59 < mst> yes
16:00 < mst> 3. The SQL Engine will have a callback system to interrogate its
              hosting ORM for info and object values
16:01 < mugwump> 4. it needs to support partial ASTs, and know how to convert
                  natural join syntax to explicit join syntax (if I've got my
                  terms right)
16:01 < mst> I think so, and I definitely get your meaning. yes.
16:02 < mugwump> 5. it needs to be easily subclassable for SQL dialects ?
16:03 < mst> 6. it should be possibly to plug into it in multiple directions to
              (a) add additional features (if you don't need complex joins,
              don't load them) and (b) allow SQL dialect support
16:17 < mugwump> also, 7. it needs to support sub-selects, named parameter
                  binding, and all other SQL constructs often overlooked, such
                  as GROUP BY & HAVING, etc.

We investigated a few CPAN modules, but none of them seemed quite flexible
enough.  SQL::Routine seemed to fit the bill, but isn't lightweight nor coded
in a style which I personally find maintainable; however it might prove to be
an invaluable source of details, or maybe it will prove easier to work with
Darren to address our concerns with the module so that it is more suitable.

Please note that this is a relatively small component of the overall picture,
and that it is very comfortably cushioned away from the user APIs of either
DBIx::Class or Tangram.  Discussion on each of the above points is encouraged.

Sam.