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 <st...@hibernate.org> wrote:
> On Tue, Jun 9, 2015 at 10:14 AM Gunnar Morling <gun...@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).
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
