hibernate-query-parser?
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
