[hibernate-dev] Hibernate ORM SQL generation

[Steve Ebersole]

On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling <gunnar at 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.