[Hibernate] RE: Looked at the new resolver code

[Steve E. <ste...@jb...>]

Moving this to the public list...

BTW, was thinking a little bit more about #2.  So all-in-all I would
much rather be able to go back to the "PropertyReferenceSource" approach
I mentioned before.  However, as I mentioned there was some trickiness
to such an approach.  The specific things I ran into (that I remember)
were:
1) The fact that a property path needed to be immediately resolved to a
join node structure when the property path occurred in the from-clause,
whereas the resolution to a join node structure needed to be delayed
until after "further dereference" in all other cases.
2) Application of join options (fetching, alias, etc) to property paths
occurring in from-clauses.=20

One thought was to find the "proper abstractions" between the different
things that need to happen in the different cases and isolate them.  I
actually started down this path somewhat initially, but opted to rip it
out just to get something that worked checked in.  As of now, I am
thinking the proper abstraction here might be:
1) Introducing an ImplicitJoinContext interface upon which the
PropertyReferenceSource nodes can call into for resolution of the next
path part. =20
2) Introduce a "driver" for this processing.  The main key here is that
there are slightly different semantics to how "intermediate path parts"
need to be handled as compared to "leaf path parts", and this driver
would encapsulate that logic (see the essentially redundant logic in
resolveCompoundPropertyReference() and handleExplicitPropertyJoin()).

-----Original Message-----
From: Joshua Davis [mailto:pg...@ya...]=20
Sent: Friday, May 12, 2006 3:44 PM
To: Steve Ebersole
Subject: Re: Looked at the new resolver code

Thanks for that.

RE: lhs - Okay, I was just a little confused by that when I first looked
at it... it's still not what I would expect but I think that's just the
nature of the 'english-like' grammar.

For example, my first thought would be to expect FROM X JOIN Y =3D> =
(FROM
(JOIN X Y)) but because the kewords preced the tokens in one case, and
not in the other that might be more trouble than it's worth. =20

Or more likely... I just think of SQL in the wrong way. :)

----- Original Message ----
From: Steve Ebersole <ste...@jb...>
To: Joshua Davis <pg...@ya...>
Sent: Friday, May 12, 2006 3:32:16 PM
Subject: RE: Looked at the new resolver code

(1) Yes, I really liked the notion of always having aliases.  It made it
much easier to see what is going on very succinctly.

(2) Initially I had it that way.  Both EntityPersisterReference and
PropertyReference implemented a common interface
(PropertyReferenceSource).  The code gets really ugly though because
there is a very seemingly minor difference between a property path in an
explicit join and one that is not.  That distinction was very difficult
to implement in that approach.

(3) Sure, 'lhs' is simply the left-hand-side of the join structure.  So
in "from Animal a join a.offspring join a.mate", "Animal a" is the 'lhs'
of both joins; or conversely, both "a.offspring" and "a.mate" share the
same left-hand-side...  Why have a have a 'lhs' on JoinNode?  Because
nodes don't know about their parents...

(4) The join conditions have not been resolved from the metadata as of
yet.  They are irrelevant at this juncture.  The only time they are
needed is when we actually go to generate SQL.  The piece that *is*
missing is (a) ad hoc join conditions and (b) WITH clause conditions.


-----Original Message-----
From: Joshua Davis [mailto:pg...@ya...]=20
Sent: Thursday, May 11, 2006 5:23 AM
To: Steve Ebersole
Subject: Looked at the new resolver code

I'm going on vacation next week so time has hard to come by, but I
wanted to
make sure I understand the new stuff before I go.

In general, it looks very good.

Here are the questions / comments I had:
* I like the 'gen:n' fake aliases, that makes everything very clear.

* I'm wondering if there is a simpler way to do what the
PropertyPathPart
classes do in HqlResolver.  It seems like something that could be done
as
the tree is traversed, but... Maybe that would end up being more
confusing.

* The join nodes form a tree where the 'lhs' of the join seems to be
it's
parent, and the rhs is the first child. For example:

Resolved AST  :   ( query ( SELECT_FROM ( from (
EntityPersisterReference
{entity-name=3Dorg.hibernate.test.hql.Animal, alias=3Da} ( JoinNode
{type=3Dinner,
source=3Dimplicit, fetch=3Dfalse, lhs=3Da} ( EntityPersisterReference
{entity-name=3Dorg.hibernate.test.hql.Animal, alias=3D<gen:0>} ( =
JoinNode
{type=3Dinner, source=3Dimplicit, fetch=3Dfalse, lhs=3D<gen:0>}
EntityPersisterReference {entity-name=3Dorg.hibernate.test.hql.Animal,
alias=3D<gen:1>} ) ) ) ) ) ) ( where ( like ( <gen:1>.name <gen:1> name =
)
'%weeble%' ) ) )
 \-[QUERY] 'query'
    +-[SELECT_FROM] 'SELECT_FROM'
    |  \-[FROM] 'from'
    |     \-[ENTITY_PERSISTER_REF] 'org.hibernate.test.hql.Animal (a)'
    |        \-[JOIN] 'join' {type=3Dinner, source=3Dimplicit, =
fetch=3Dfalse,
lhs=3Da}
    |           \-[ENTITY_PERSISTER_REF] 'org.hibernate.test.hql.Animal
(<gen:0>)'
    |              \-[JOIN] 'join' {type=3Dinner, source=3Dimplicit,
fetch=3Dfalse, lhs=3D<gen:0>}
    |                 \-[ENTITY_PERSISTER_REF]
'org.hibernate.test.hql.Animal (<gen:1>)'
    \-[WHERE] 'where'
       \-[LIKE] 'like'
          +-[PROPERTY_REF] '<gen:1>.name'
          |  +-[ALIAS] '<gen:1>'
          |  \-[IDENT] 'name'
          \-[QUOTED_STRING] ''%weeble%''

So, if there was another join from 'Animal a', it would be a child of
the
topmost ENTITY_PERSISTER_REF, right?  So, I'm not sure I understand the
idea
of 'lhs' in the join node.

* Also regarding joins: Can you help me find where the join condition is
represented? I seem to have missed that.

- Josh