[hibernate-dev] Query Parser Redesign

Wed Aug 26 14:38:35 EDT 2015

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