Hi Steve, > 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. Thanks, --Gunnar _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev