[hibernate-dev] Query handling : Antlr 3 versus Antlr 4

[Gunnar Morling]

2015-06-09 22:11 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> So today I spent some time cleaning up the basic HQL parser.  Personally I
> think it would be best if our 2 proof-of-concepts could share that first
> grammar.  IMO that would make the differences between the 2 approaches more
> apparent.  I will push those changes soon.
>

Ok, I can try and work on a PoC for the decorator-based approach. Not sure
what the outcome will be, as your's, my understanding of it is roughly
vague and high-level. But if it fails we can maybe settle for the Antlr3
approach with the better feeling of having investigated the alternative.

Can you let me know when you have pushed your stuff? What does it do,
render the query below as SQL?

It is not complete yet.  But it covers most cases.
>
>
> On Tue, Jun 9, 2015 at 10:47 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> On Tue, Jun 9, 2015 at 10:14 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>> Yes, indeed I cheated here a bit. Probably it should be the following
>>> instead:
>>>
>>>       [DOT] ---> AttributeReference("<gen:1>", "code")
>>>         [DOT]
>>>           [DOT]
>>>             [IDENT, "c"]
>>>             [IDENT, "headquarters"]
>>>           [IDENT, "state"]
>>>         [IDENT, "code"]
>>>
>>
>> How do you identify one DOT as referring to something else versus any of
>> the other DOTs?
>>
>>
>> Or maybe something like:
>>>
>>>     [SELECTION_PARTICLE] ---> AttributeReference("<gen:1>", "code")
>>>       [DOT]
>>>         [DOT]
>>>           [DOT]
>>>             [IDENT, "c"]
>>>             [IDENT, "headquarters"]
>>>           [IDENT, "state"]
>>>         [IDENT, "code"]
>>>
>>> Where SELECTION_PARTICLE would be an abstract representation of anything
>>> that can be selected (attribute ref, Java literal ref etc.) and the
>>> decorator element added in a later pass would specify its actual semantics
>>> based on the alias definitions etc. discovered before.
>>>
>>> Bottom line being, that decorators providing semantics are attached to
>>> the nodes of the parse tree based on information gathered in previous
>>> passes.
>>>
>>
>> And what does that look like in real, practical terms?   That's what
>> concerns me :)  I don't know, and you are just speaking in generalities.
>> So what does that look like in practice?
>>
>>
>> Not into the tree itself, but we can encode that semantic resolution into
>>> decorators (node attachments).
>>>
>>
>> Again, what do these "node attachments" look like in  practice?  I have
>> zero clue and based on my discussions with Antlr folks its not pretty.
>> Maybe I misunderstand.  But if you are proposing this approach, I would
>> think you should have an idea of how it would look practically-speaking :)
>>  Maybe this is the way to go, I just need to see what this looks like.
>>
>>
>> Yes, they would deal with [[DOT][IDENT]] nodes but would benefit from
>>> semantic decorators attached previously. During rendering I would expect
>>> mainly those attachments to be of importance for the query creation.
>>>
>>> Admittedly, that's all quite "high level", but so far it seems doable to
>>> me in principle. It doesn't answer of course actual tree transformations
>>> such as (x + 0) -> x. I am not sure whether there are cases like this.
>>>
>>
>> Yes it is all extremely high-level.  That is my concern.  Principle and
>> practice are often 2 very different things.
>>
>> I plan on spending some time taking my hibernate-antlr4-poc project and
>> expanding it specifically to try the "second grammar" approach and see what
>> practical difficulties that shakes out.  Would you be willing to do the
>> same for this decorated approach?  Then we'd have concrete stuff to compare
>> and base a decision on.
>>
>> Also, `(x + 0) -> x` is actually a quite simple case.   Ours is much more
>> complicated.  In analyzing `c.headquarters.state.code` in the SELECT clause
>> we need a few things to happen in a few different parts of the tree.  We
>> need:
>> 1) `c.headquarters.state` to be transformed into 2 "implicit joins" in
>> the FROM clause
>> 2) we need to replace `c.headquarters.state.code` as
>> `{implicit-alias}.code` in the SELECT
>> 3) register `c.headquarters` and `c.headquarters.state` as implicit join
>> paths (additional implicit joins using these paths should re-use the same
>> joins).
>>
>