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

[Steve Ebersole]

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.

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).
>