[hibernate-dev] Hibernate ORM SQL generation

Mon Aug 24 10:39:58 EDT 2015

I agree in the case where "the query includes more than one".  However,
there are definitely valid uses for these.

Consider this case e.g...

interface Auditable {
    String createdBy;
    Instant createdAt;
    String updatedBy;
    Instant updatedAt;
}

@Entity
class Account implements Auditable {
    ...
}

@Entity
class Fund implements Auditable {
    ...
}

etc.

And a query to get all records created by a person within a date range:

"from Auditable a where a.createdBy = :person and a.createdAt between
:start and :end"

Is a perfectly valid (and useful!) query.

On Mon, Aug 24, 2015 at 9:25 AM Brett Meyer <brett at hibernate.org> wrote:

> In practice, when are unmapped inheritance queries typically used?  I
> tend to see them only for bulk deletions, IIRC.  But in general, I'd
> assume they're a product of "doing something incorrectly", especially if
> the query includes more than one. On 08/24/2015 08:40 AM, andrea boriero
> wrote:
> >   I have nothing against your proposal so +1
> >
> > On 24 August 2015 at 04:55, Steve Ebersole <steve at hibernate.org> wrote:
> >
> >> Another point I want to discuss up from because it affects tree
> >> structure.  Specifically the idea of an "unbounded implicit inheritance"
> >> query.  These are queries like "from java.lang.Object".  Queries where
> the
> >> from clause pulls in "unmapped inheritance".  These are fine, to an
> >> extent.  Hibernate has natively supported these since way back[1].
> >>
> >> What is problematic is cases where we have more than one "unmapped
> >> inheritance" reference.  E.g. "from java.lang.Object o1,
> java.lang.Object
> >> o2".  In fact its the same difficulty as an unbounded cartesian product,
> >> but here in terms of the number of SQL queries we need to
> produce/execute.
> >>
> >> So I propose that we allow just one "unmapped inheritance" reference per
> >> query.
> >>
> >> [1] Reminder to self... another "strict JPQL compliance" consideration.
> >>
> >> On Sat, Aug 22, 2015 at 1:16 PM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> I got that initial refactoring pushed to my fork...
> >>>
> >>> On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> Just a heads up that I started a major refactoring of the antlr4 poc
> >>>> project in preparation for starting to look at this next sql-gen step.
> >>>>
> >>>> First I am making it into a multi-module project.  We will have the
> >>>> hql-parser module, but then also an orm-sql-gen module to be able to
> play
> >>>> with that part.  This makes sure we are not blending orm concerns
> into the
> >>>> pure hql parser.
> >>>>
> >>>> Also, I started working on splitting the "semantic query" model out
> into
> >>>> a separate module as well.  There are a few reasons for this.  I wont
> go
> >>>> into them all here.  The main one being that HQL is just one producer
> of
> >>>> this semantic model.   Rather than another long name I went with the
> >>>> acronym SQM (Semantic Query Model) here.  The top package being
> >>>> org.hibernate.sqm.
> >>>>
> >>>> These changes already illustrated some tighter couplings then I had
> >>>> intended, so it was a good exercise.  I'll push once I get those
> couplings
> >>>> cleaned up.
> >>>>
> >>>> On Fri, Aug 21, 2015 at 2:35 PM andrea boriero <dreborier at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> I haven't seen it, I'm going to read it.
> >>>>>
> >>>>> On 21 August 2015 at 16:54, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>>>
> >>>>>> http://www.antlr2.org/article/1170602723163/treewalkers.html
> >>>>>>
> >>>>>> Not sure if y'all have seen this.  Its an old article advocating
> >>>>>> manual tree walking (what we are facing here) over using generated
> tree
> >>>>>> walkers.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Aug 19, 2015 at 12:27 PM Steve Ebersole <
> steve at hibernate.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I agree.  Its my biggest hang up with regard to using Antlr 4.
> >>>>>>> Actually, its my only hang up with Antlr 4, but its a huge one.
> >>>>>>>
> >>>>>>> On Tue, Aug 18, 2015 at 9:30 AM andrea boriero <
> dreborier at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> yes Steve I'm more familiar with Antlr4 ( but not 3) and I gave a
> >>>>>>>> look at your poc.
> >>>>>>>>
> >>>>>>>> Apart some problems to fully understand the semantic model (due to
> >>>>>>>> my lack of a complete knowledge of the domain problem),
> >>>>>>>> I agree with you about the simplicity and elegance of  the grammar
> >>>>>>>> for HQL recognition and semantic model building.
> >>>>>>>>
> >>>>>>>> What I don't like it's the necessity to build our own semantic
> model
> >>>>>>>> walker/s in order to produce the final SQL.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 14 August 2015 at 16:32, Steve Ebersole <steve at hibernate.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> We've had a few discussions about this in the past.  As 5.0 is
> >>>>>>>>> getting
> >>>>>>>>> close to Final (next week), its time to start contemplating our
> >>>>>>>>> next major
> >>>>>>>>> tasks.  The consensus pick for that has been the idea of a
> "unified
> >>>>>>>>> SQL
> >>>>>>>>> generation engine" along with a shared project for the semantic
> >>>>>>>>> analysis of
> >>>>>>>>> HQL/JPQL (and recently it was decided to include JPA Criteria
> >>>>>>>>> interpretation here as well).
> >>>>>>>>>
> >>>>>>>>> The central premise is this.  Take the roughly 6 or 7 different
> >>>>>>>>> top-level
> >>>>>>>>> ways Hibernate generates SQL and combine that into one "engine"
> >>>>>>>>> based on
> >>>>>>>>> the input of a "semantic tree".  The mentioned HQL/JPQL/Criteria
> >>>>>>>>> shared
> >>>>>>>>> project will be one producer of such semantic trees.  Others
> would
> >>>>>>>>> include
> >>>>>>>>> persisters (for insert/update/delete requests) and loaders (for
> load
> >>>>>>>>> requests).
> >>>>>>>>>
> >>>>>>>>> We have a lot of tasks for this overall goal still remaining.
> >>>>>>>>>
> >>>>>>>>> We still have to finalize the design for the HQL/JPQL/Criteria to
> >>>>>>>>> semantic
> >>>>>>>>> tree translator.  One option is to proceed with the Antlr 4 based
> >>>>>>>>> approach
> >>>>>>>>> I started a PoC for.  John has been helping me some lately with
> >>>>>>>>> that.  The
> >>>>>>>>> first task here is to come to a consensus whether Antlr 4 is the
> >>>>>>>>> way we
> >>>>>>>>> want to proceed here.  We've been over the pros and cons before
> in
> >>>>>>>>> detail.
> >>>>>>>>> In summary, there is a lot to love with Antlr 4.  Our grammar for
> >>>>>>>>> HQL
> >>>>>>>>> recognition and semantic tree building is very simple and elegant
> >>>>>>>>> imo.  The
> >>>>>>>>> drawback is clearly the lack of tree walking, meaning that we are
> >>>>>>>>> responsible for writing by hand our walker for the semantic tree.
> >>>>>>>>> In fact
> >>>>>>>>> multiple, since each consumer (orm, ogm, search) would need to
> >>>>>>>>> write their
> >>>>>>>>> own.  And if we decide to build another AST while walking the
> >>>>>>>>> semantic
> >>>>>>>>> tree, we'd end up having to hand-write yet another walker for
> those.
> >>>>>>>>>
> >>>>>>>>> What I mean by that last part is that there are 2 ways we might
> >>>>>>>>> choose to
> >>>>>>>>> deal with the semantic tree.  For the purpose of discussion,
> let's
> >>>>>>>>> look at
> >>>>>>>>> the ORM case.  The first approach is to simply generate the SQL
> as
> >>>>>>>>> we walk
> >>>>>>>>> the semantic tree; this would be a 2 phase interpretation
> approach
> >>>>>>>>> (input
> >>>>>>>>> -> semantic tree -> SQL).  That works in many cases.  However it
> >>>>>>>>> breaks
> >>>>>>>>> down in other cases.  This is exactly the approach our existing
> HQL
> >>>>>>>>> translator uses.  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.
> >>>>>>>>> And not to mention integrating things like follow-on fetches and
> >>>>>>>>> other
> >>>>>>>>> enhancements we want to gain from this.  My vote is definitely
> for
> >>>>>>>>> 3 or
> >>>>>>>>> more phases of interpretation.  The problem is that this is
> exactly
> >>>>>>>>> where
> >>>>>>>>> Antlr 4 sort of falls down.
> >>>>>>>>>
> >>>>>>>>> So first things first... we need to decide on Antlr 3 versus
> Antlr 4
> >>>>>>>>> (versus some other parser solution).
> >>>>>>>>>
> >>>>>>>>> Next, on the ORM side (every "backend" can decide this
> >>>>>>>>> individually) we
> >>>>>>>>> need to decide on the approach for semantic-tree to SQL
> >>>>>>>>> translation, which
> >>>>>>>>> somewhat depends on the Antlr 3 versus Antlr 4 decision.
> >>>>>>>>>
> >>>>>>>>> We really need to decide these things ASAP and get moving on them
> >>>>>>>>> as soon
> >>>>>>>>> as ORM 5.0 is finished.
> >>>>>>>>>
> >>>>>>>>> Also, this is a massive undertaking with huge gain potentials for
> >>>>>>>>> not just
> >>>>>>>>> ORM.  As such we need to understand who will be working on this.
> >>>>>>>>> Sanne,
> >>>>>>>>> Gunnar... I know y'all have a vested interest and a desire to
> work
> >>>>>>>>> on it.
> >>>>>>>>> John, I know the same is true for you.  Andrea?  Have you had a
> >>>>>>>>> chance to
> >>>>>>>>> look over the poc and/or get more familiar with Antlr?
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>>> hibernate-dev mailing list
> >>>>>>>>> hibernate-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>>>
> >>>>>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>