2015-08-26 14:41 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling
<gunnar(a)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.