[hibernate-dev] Hibernate ORM SQL generation

[Steve Ebersole]

Nevermind.  I will not do that.  I think I have found a still-easyish way
to do it.


On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole <steve at hibernate.org> wrote:

> I do want to pull ORM in to the hibernate-sqm module as a test dependency
> to be able to more easily set up the ModelMetadata stuff based on a
> SessionFactory.  That is possibly awkward later when we then use
> hibernate-sqm in ORM in terms of having 2 different versions of ORM.  I am
> open to alternatives that don't involve *me* developing a real(ish) ModelMetadata
> impl from scratch.
>
> On Thu, Aug 27, 2015 at 8:45 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 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.
>>
>