Re: [hibernate-dev] Query Parser Redesign

I think I'd like to rename this repo and the 2 modules. I think its easier to call the overall repo hibernate-sqm. And then within that rename the 2 modules: * hibernate-sqm -> hibernate-sqm-model * hibernate-query-interpreter -> ? Still not sure what to call this "query->SQM" module. Thoughts? On Wed, Aug 26, 2015 at 1:39 PM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 26 August 2015 at 18:27, Steve Ebersole <steve(a)hibernate.org&gt; 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 <steve(a)hibernate.org&gt; > wrote: > > > >> Yes > >> > >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar(a)hibernate.org&gt; > 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 <steve(a)hibernate.org&gt;: > >>> > I also created Jira project -> > >>> https://hibernate.atlassian.net/projects/SQM > >>> > > >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve(a)hibernate.org&gt; > >>> 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 < > andrea(a)hibernate.org&gt; > >>> >> wrote: > >>> >> > >>> >>> no objections > >>> >>> > >>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve(a)hibernate.org&gt; > >>> 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 < > dreborier(a)gmail.com&gt; > >>> >>>> wrote: > >>> >>>> > >>> >>>>> I see, > >>> >>>>> > >>> >>>>> Thanks > >>> >>>>> > >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve(a)hibernate.org&gt; > >>> 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 < > >>> dreborier(a)gmail.com&gt; > >>> >>>>>> 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 < > steve(a)hibernate.org&gt; > >>> >>>>>>> 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(a)lists.jboss.org > >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> >>>>>>>> > >>> >>>>>>> > >>> >>>>>>> > >>> >>>>> > >>> >>> > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev(a)lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev