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 >

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 >>> >> >>

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 >>>>> >>>> >>>> >>

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

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 >

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-query-parser? 2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: > 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 > >> >>> 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

On 26 August 2015 at 23:20, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I'm ok with that. Everyone else? > > > On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> hibernate-query-parser? +1 >> >> 2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev