ToDo

Tests for: MutableBooleanExpression, later Modification of Query (like QueryBuilder)
thorough test of syntax
documentation
distinct
Hints
Interfaces for all expression Types
- distinguish elementary (typed) Expressions (boolean, numeric, field, constant, string, param)
- and composed (unary, binary, tuple, rowtuple, columntuple, table, sql)
check()
- used tables are referred to in from
- order by columns numeric or in select
- columns in select others with aggregate functions in group by in having
toStatement(DataSource) via StatementCreator
- with no Params (extract vom Sql-Tree) queryForInt,queryForObject,queryForMap,queryForList,query
- RowMapper, RowCallbackHandler
- BeanRowCallbackHandler, BeanRowMapper processRow / mapRow(BeanInterface bean) (with dynamic Proxy and Reflection, each ResultSet row encapsulated behind the bean Interface)
- ValueRowCallbackHandler, ValueRowMapper mapRow / processRow(int oid, String name, BigDecimal price) (handle via reflection and result set column order (getObject(index), (optional: if needed convert values)
- delete, update, execute()

Ideas for Use

Put production SQL into own classes (kind of .sql.java) as Subclasses of Sql (e.g. class ARTICLE_SELECT extends Sql {{ select()....; }}
- easier testable (scan code for all subclasses of Sql and execute them against the database)
- test query params and result assertions could be put into the class itself (?? testcode in production, separation of concerns?)
- or add TestCases for these Sql-subclasses

order of importance/probility of implementation

Decide on subset of SQL-select to implement OR follow demand driven approach (foobar)
discuss partitioning (modularisation) of table java file (Module classes or packages or no partitioning (less imports))
case when expression
check validity of SQL Statement (without database) (foobar)
different target languages
sql to jequel parser (baum)
sql optimization (baum)
jequel to DDL, i.e. generate CREATE TABLE from Java (foobar)