On 26 August 2015 at 18:27, Steve Ebersole <st...@hibernate.org> wrote: > Yes, but at this point lets make sure there is a Jira for any changes we > are making. > > Also, I wanted to be specific that *no* clients of this code belong in this > repo. I know y'all did that with the hibernate-hql-parser repo. I just > want to be clear that that should *not* happen here.
We had a short chat about this ^ on IRC; in summary I agree but we'll have to deal with the following difficulties. The obvious limitation of that is that each other project implementing a tree walker will need to (potentially) adjust on internal tree changes, but since that's obviously needed only when you upgrade the parser version you want to use, the problem is deferred; assuming we don't actually start all implementing such walkers until the tree is relatively stable, that should be a fair enough limitation to not push the burden of maintenance on the main parser maintainers, but keep the effort as an opt-in choice for those wishing to upgrade. The other little negative of that approach is that the current backend which generates Lucene queries depends on Hibernate Search and is consumed by both Hibernate OGM and by Infinispan, so having each "consuming project" host the tree walker would either prevent OGM and Infinispan to share the effort, or that would need an additional separate repository, or we could host it within Hibernate Search as some kind of parasite module (I'd rather not, for the same maintenance reason). We also wondered if the new parser should eventually be incorporated within the Hibernate ORM repository. In terms of dependencies it would not depend on hibernate-core so this would have no impact on other consumers, other than coupling the release cycle to ORM. Maybe this is premature to discuss as we certainly don't want it in there at least until ORM actually uses it, but I think that for end users it would be helpful to not have another dependency version to align.. Thanks, Sanne > > On Wed, Aug 26, 2015 at 7:15 AM Steve Ebersole <st...@hibernate.org> wrote: > >> Yes >> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gun...@hibernate.org> wrote: >> >>> +1 for the new repo. Just forked it and am looking into the amazing >>> things you guys built recently :) >>> >>> Can I push simple stuff to that repo right away (e.g. adding the >>> Eclipse plug-in to build.gradle)? >>> >>> Cheers, >>> >>> --Gunnar >>> >>> >>> 2015-08-26 0:17 GMT+02:00 Steve Ebersole <st...@hibernate.org>: >>> > I also created Jira project -> >>> https://hibernate.atlassian.net/projects/SQM >>> > >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <st...@hibernate.org> >>> wrote: >>> > >>> >> I am starting that work here -> >>> >> https://github.com/hibernate/hibernate-semantic-query >>> >> >>> >> >>> >> On Tue, Aug 25, 2015 at 2:21 PM andrea boriero <and...@hibernate.org> >>> >> wrote: >>> >> >>> >>> no objections >>> >>> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole <st...@hibernate.org> >>> wrote: >>> >>> >>> >>>> Anyone want to propose an alternative approach to what I have >>> working in >>> >>>> my Antlr 4 PoC? >>> >>>> >>> >>>> If not, I think we should move that work to a GitHub Hibernate org >>> repo >>> >>>> and start tracking work and Jiras there. Objections? >>> >>>> >>> >>>> Also its no longer *just* HQL, we also plan to support JPA criteria >>> >>>> queries here, interpreting them into semantic query models. As such >>> I >>> >>>> propose the top-level name of hibernate-query-parser, with 2 sub >>> projects: >>> >>>> hibernate-sqm and hibernate-query-interpreter >>> >>>> >>> >>>> >>> >>>> On Tue, Aug 25, 2015 at 8:45 AM andrea boriero <drebor...@gmail.com> >>> >>>> wrote: >>> >>>> >>> >>>>> I see, >>> >>>>> >>> >>>>> Thanks >>> >>>>> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <st...@hibernate.org> >>> wrote: >>> >>>>> >>> >>>>>> from A a where a.b in (from B b ..) and a.c in (from C c ...) ... >>> >>>>>> >>> >>>>>> But regardless, the children are not important for a stack, just >>> the >>> >>>>>> parent. As I said when we discussed on ORC, the children are just >>> >>>>>> maintained because I used them for tests. >>> >>>>>> >>> >>>>>> On Tue, Aug 25, 2015 at 6:53 AM andrea boriero < >>> drebor...@gmail.com> >>> >>>>>> wrote: >>> >>>>>> >>> >>>>>>> Hi Stevej >>> >>>>>>> >>> >>>>>>> I'm playing with you idea to remove the parent/child from the >>> >>>>>>> FromClause and introduce such a structure in the >>> FromClauseProcessor. >>> >>>>>>> >>> >>>>>>> just a question, in the current implementation a fromClause can >>> have >>> >>>>>>> more than one child fromClause , but I cannot figure out when >>> this happen :( >>> >>>>>>> >>> >>>>>>> Thanks a lot >>> >>>>>>> >>> >>>>>>> On 25 August 2015 at 04:12, Steve Ebersole <st...@hibernate.org> >>> >>>>>>> wrote: >>> >>>>>>> >>> >>>>>>>> Andrea, this is in relation to something you asked me on IRC >>> today. >>> >>>>>>>> Specifically in regards to FromClause and the fact that it >>> maintains >>> >>>>>>>> pointers to parent/children. As I said on IRC there is no >>> intrinsic >>> >>>>>>>> need >>> >>>>>>>> (I do not foresee) for keeping this structure; I really only did >>> that >>> >>>>>>>> because FromCauseProcessor needed a stack of FromClauses and the >>> >>>>>>>> FromClause >>> >>>>>>>> itself made a simple place to do that. >>> >>>>>>>> >>> >>>>>>>> However, in later work I ran into minor problems because of that >>> >>>>>>>> decision. >>> >>>>>>>> I need to make a copy of an entire SelectStatement tree. But >>> >>>>>>>> because the >>> >>>>>>>> FromClause is held twice (for non-root FromClauses) in the tree, >>> it >>> >>>>>>>> makes >>> >>>>>>>> it more complicated to do a "simple copy" than it need be. >>> >>>>>>>> Basically I >>> >>>>>>>> need to maintain a "Map<FromClause,FromClause> copy Map" :( >>> >>>>>>>> >>> >>>>>>>> Long story short, I think I might revisit that decision and >>> instead >>> >>>>>>>> write a >>> >>>>>>>> dedicated stack in FromClauseProcessor for this. In the >>> morning... >>> >>>>>>>> its too >>> >>>>>>>> late to start something that ambitious tonight. I'll start that >>> in >>> >>>>>>>> the >>> >>>>>>>> morning, unless someone wants to pick that up in the next few >>> hours >>> >>>>>>>> before >>> >>>>>>>> I get back on line. >>> >>>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>>> 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
