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
