[hibernate-dev] Hibernate ORM SQL generation

[Gunnar Morling]

2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> 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.

Yes, that'd be good I think. We'd have to apply the same rules for
splitting as ORM.

>
> BTW, another cool thing to note is the (still expanding) support for "strict
> JPQL compliance" enforcement.