On 26 August 2015 at 23:20, Steve Ebersole <st...@hibernate.org> wrote: > I'm ok with that. Everyone else? > > > On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling <gun...@hibernate.org> wrote: >> >> hibernate-query-parser?
+1 >> >> 2015-08-26 22:32 GMT+02:00 Steve Ebersole <st...@hibernate.org>: >> > 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 <sa...@hibernate.org> >> > wrote: >> > >> >> 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 >> >> >> > _______________________________________________ >> > 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
