On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gun...@hibernate.org> wrote:
> 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 ORM the only time this happens today for a SELECT query is in the "split query" case I mentioned elsewhere (a query like 'from java.lang.Object'). SQM does this much better than we do in ORM today. in SQM we build a semantic tree that encodes the "unmapped polymorphism" such that we get a tree with 'java.lang.Object' as the root from element. But it is a FromElement with a special type of EntityTypeDescriptor (which comes from the caller remember): PolymorphicEntityTypeDescriptor. On the ORM side then I have a QuerySplitter that takes that query and makes a copy of that entire SQM tree, one for each mapped implementor of the specified class. FWIW, ORM does this today, albeit in a different way. Today we split the query based on String manip and then feed it parser. Here we feed it to the parser and use the tree to split it; much less brittle :) Really the cases where this would happen (one "concrete SQM" -> multiple SQL) would be UPDATE and DELETE queries against "multi-table structures" (inheritance, secondary tables). 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. > OGM would be doing this. This SQM is the end result of the shared library. WHat each caller does with the SQM is up to that particular caller. We should consider moving QuerySplitter (its in my PoC, which now acts as the PoC for using this in ORM) into the hibernate-sqm module. Any caller wanting to support those unmapped class references will need to do the same thing. BTW, another cool thing to note is the (still expanding) support for "strict JPQL compliance" enforcement. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev