[hibernate-dev] Query Parser Redesign

[Sanne Grinovero]

On 26 August 2015 at 23:20, Steve Ebersole <steve at hibernate.org> wrote:
> I'm ok with that.  Everyone else?
>
>
> On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> hibernate-query-parser?

+1

>>
>> 2015-08-26 22:32 GMT+02:00 Steve Ebersole <steve at 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 <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
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev