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.
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. 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:[EMAIL PROTECTED] 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 => (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. Or more likely... I just think of SQL in the wrong way. :) ----- Original Message ---- From: Steve Ebersole <[EMAIL PROTECTED]> To: Joshua Davis <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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=org.hibernate.test.hql.Animal, alias=a} ( JoinNode {type=inner, source=implicit, fetch=false, lhs=a} ( EntityPersisterReference {entity-name=org.hibernate.test.hql.Animal, alias=<gen:0>} ( JoinNode {type=inner, source=implicit, fetch=false, lhs=<gen:0>} EntityPersisterReference {entity-name=org.hibernate.test.hql.Animal, alias=<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=inner, source=implicit, fetch=false, lhs=a} | \-[ENTITY_PERSISTER_REF] 'org.hibernate.test.hql.Animal (<gen:0>)' | \-[JOIN] 'join' {type=inner, source=implicit, fetch=false, lhs=<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 ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
