The other approach is to use a 3-phase translation (input
-> semantic-tree -> semantic-SQL-tree(s) -> SQL). This gives a hint to one
of the major problems. One source "semantic" query will often correspond
to multiple SQL queries; that is hard to manage in the 2-phase approach.
In which situations will this happen? I can see inheritance where a
HQL query targeting a super-type needs to be translated into a SQL
query per sub-type table. What others are there?
For the purposes of OGM this phase ideally would not be tied to SQL,
as we phase the same task with non-SQL backends in SQL. I.e. i'd be
beneficial to have input -> semantic-tree ->
semantic-output-query-tree(s) -> (SQL|non-SQL query). There
"semantic-output-query-tree(s)" would be an abstract representation of
the queries to be executed, e.g. referencing the table name(s). But it
would be unaware of SQL specifics.