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 <br...@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 <st...@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 <st...@hibernate.org>
> >> wrote:
> >>
> >>> I got that initial refactoring pushed to my fork...
> >>>
> >>> On Fri, Aug 21, 2015 at 3:51 PM Steve Ebersole <st...@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 <drebor...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> I haven't seen it, I'm going to read it.
> >>>>>
> >>>>> On 21 August 2015 at 16:54, Steve Ebersole <st...@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 <
> st...@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 <
> drebor...@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 <st...@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@lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>>>>>
> >>>>>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
