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
