> -----Original Message-----
> From: Fay Wang [mailto:fyw...@yahoo.com]
> Sent: Wednesday, December 30, 2009 1:47 PM
> To: users@openjpa.apache.org
> Subject: Re: How to implement a map where the key is in the join
table,
> not in the target table?
> 
> For JPA 2.0 (OpenJPA trunk), the map key does not need to be a field
in
> the target entity. For example, please see the test case in
> org.apache.openjpa.persistence.jdbc.maps.*.

I assume the following is the relevant excerpt?  This appeared to be the
only example of this in that package, although I'm looking at the M3
distribution, not the trunk.

    @ManyToMany
    @JoinTable(name="CENROLLS",
            joincolum...@joincolumn(name="STUDENT"),
            inversejoincolum...@joincolumn(name="SEMESTER"))
            @MapKeyJoinColumn(name="COURSE")    
            Map<Course, Semester> enrollment =
                new HashMap<Course, Semester>();

> ----- Original Message ----
> From: "KARR, DAVID (ATTCINW)" <dk0...@att.com>
> To: users@openjpa.apache.org
> Sent: Tue, December 29, 2009 9:36:53 AM
> Subject: How to implement a map where the key is in the join table,
not
> in the target table?
> 
> The information I've read about the "map" construct is that the key
> value used in the map is taken from a field in the target entity.  I
> have a situation where I need to define a map where the key value is a
> column in a join table, not the target table.
> 
> Here's an example of the structure I have:
> 
> Table FOO:
> ----------
> VARCHAR FOO_ID
> INT TYPE
> 
> Table FOO_BILLING_INFO:
> ------------------
> VARCHAR FOO_ID
> VARCHAR BILLING_SYSTEM
> VARCHAR BILLING_INFO_ID
> 
> Table BILLING_INFO:
> -------------------
> VARCHAR BILLING_INFO_ID
> VARCHAR BILL_CODE
> VARCHAR SYSTEM_NAME
> 
> There is a "OneToMany" relationship from FOO to BILLING_INFO.  The
"key
> value" for the map is intended to be the "BILLING_SYSTEM" value in the
> join table.  Also note that the values of "BILLING_SYSTEM" are not the
> same as or related to the values for "SYSTEM_NAME" in BILLING_INFO
> (that
> was my first guess).
> 
> For each unique value of "FOO_ID" in "FOO", there will be two
> "FOO_BILLING_INFO" rows with different "BILLING_SYSTEM" values, and
> each
> of those two rows will point to a "BILLING_INFO" row, sometimes the
> same
> one for both "FOO_BILLING_INFO" rows, but sometimes not.
> 
> 
> 
> 

Reply via email to