[Hibernate-issues] [Hibernate-JIRA] Created: (HB-109) Handle Entities with composite keys in HQL join criteria

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-109


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-109
    Summary: Handle Entities with composite keys in HQL join criteria
       Type: Improvement

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Gunther Schadow

    Created: Tue, 27 May 2003 7:17 PM
    Updated: Tue, 27 May 2003 7:17 PM
Environment: any

Description:
Composite keys are a proper RDBMS idiom and Hibernate supports them
fairly well. However, there are some non-orthogonal behaviors with 
composite keys in HQL.

(1) while Entity types can be used in HQL join clauses (e.g., "from Person sibling1, Person sibling2 where sibling1.father = sibling2.father"), if the entity has a composite key, the above query stops working (non-atomic path.)

(2) while one can pass an Entity type into a HQL bind variable (e.g., "from Person child where child.father = :father", where we setEntity("father",(Father)myFather);) this stops working when the entity has a composite key.

Further investigation shows that in the case (2), the bind-variable mechanism of Hibernate already properly detects the case of composite keys and binds two variables in the java.sql.PreparedStatement. However, the statement that Hibernate generates can't handle the composite entity ids.

The focus of the improvement would be somewhere in the hql.WhereParser or callers of it. At this point the WhereParser calls the PathExpressionParser.getWhereColumn() method instead of handling getWhereColumns().

The workaround is to write the HQL query (1) as "... where sibling1.father.id1 = sibling2.father.id1 AND sibling1.father.id2 = sibling2.father.id2 = ...", and for query (2) analogously. Notice also that HQL does not permit a composite bind variable's property to be accessed. So, "... where child.father.id1 = :father.id1 AND child.father.id2 = :father.id2 ..." is not possible to write (leads to all sorts of parser errors.) 

With ideomatic Java AND ideomatic RDBM, a mapper that can handle joins independent of whether keys are atomic or composite is highly desirable. That way a system is more stable vis-a-vis changes in the key strategy. The key design can be properly encapsulated and the details need not be exposed on the HQL layer. 


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira