[hibernate-dev] Query Parser Redesign

[Steve Ebersole]

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 at hibernate.org> wrote:

> On 26 August 2015 at 18:27, Steve Ebersole <steve at 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 <steve at hibernate.org>
> wrote:
> >
> >> Yes
> >>
> >> On Wed, Aug 26, 2015, 1:48 AM Gunnar Morling <gunnar at 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 <steve at hibernate.org>:
> >>> > I also created Jira project ->
> >>> https://hibernate.atlassian.net/projects/SQM
> >>> >
> >>> > On Tue, Aug 25, 2015 at 3:56 PM Steve Ebersole <steve at 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 <
> andrea at hibernate.org>
> >>> >> wrote:
> >>> >>
> >>> >>> no objections
> >>> >>>
> >>> >>> On 25 August 2015 at 20:12, Steve Ebersole <steve at 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 at gmail.com>
> >>> >>>> wrote:
> >>> >>>>
> >>> >>>>> I see,
> >>> >>>>>
> >>> >>>>> Thanks
> >>> >>>>>
> >>> >>>>> On 25 August 2015 at 13:17, Steve Ebersole <steve at 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 <
> >>> dreborier at 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 <
> steve at 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 at lists.jboss.org
> >>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >>>>>>>>
> >>> >>>>>>>
> >>> >>>>>>>
> >>> >>>>>
> >>> >>>
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>