Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of saintx.opensource@gmail.com
 designates 66.249.82.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=wBYvtreF3v6VWmVtEIA/x7RYIZpOX2OVCrQ0p2EBU3f7DwdoyAoY6xOHK+BP01Q1TBg/iPlJn7ZzmcaWGRrZvl/1Z+xCq9LOnDW9jd56dGdJkxpE8DCIse5BJ4d/rhfquKZ/uu8n++lxq8h86vIITYPpheEsezXOJkC6MFJDnuU=
Message-ID: <b0a94a6d0801110626y6ebdccc2oe6e39076857b7c69@mail.gmail.com>
Date: Fri, 11 Jan 2008 08:26:16 -0600
From: "Alexander Saint Croix" <saintx.opensource@gmail.com>
To: users@openjpa.apache.org
Subject: Re: Using a Maps instead of Sets to handle @ManyToMany?
In-Reply-To: <14743250.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_583_6927519.1200061576397"
References: <14743250.post@talk.nabble.com>

------=_Part_583_6927519.1200061576397
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Cedric,

I might be able to help you with this.  I just got done implementing this in
my Open Source CORM project, for which the corm-party library is undergoing
CRUD and cascade testing.

There is an @MapKey annotation outlined near the bottom of the EJB
3.0Persistence specification that should shed some light on your
problem--did
for me.  There is also a proprietary @PersistentMap annotation that (I
believe) OpenJPA provides.  You'll have to continue to inquire about that.
I didn't end up using either of these solutions.

For my part, I ended up implementing Property and PropertyKey classes, and
an association class, AssociatedAddress, to bridge the gap between Address
and Party.  Since addresses can be associated with numerous parties and
parties can have numerous addresses, it's inevitable that there'll be an
association table anyway, but since address_party associations are important
enough to warrant having their own metadata, I created a class that has a
reference to Party, one to Address, and a set of Property objects.  Each
property has one PropertyKey (with its own String 'name') and one String
'value', for normalization purposes (chances are this'll get further
refactored before it's done).

I owe the idea for this to Roger Mori, a good acquaintence of mine.

After looking at the Map persistence options, and after considering
long-term normalization problems, I felt it was better to implement my own
property tables for association metadata.  I now use it in a handful of
other locations throughout the project.


On Jan 10, 2008 2:43 PM, Cedric Hurst <cedric.hurst@gmail.com> wrote:

>
> I have a domain model which can be simplified as follows:
>
> // AddressType.java
>
> public enum AddressType implements java.io.Serializable {
>        BILLING,
>        SHIPPING;
> }
>
> // Address.java
>
> import javax.persistence.*;
> import java.util.*;
>
> @Entity
> public class Address implements java.io.Serializable {
>        @Id @GeneratedValue
>        public long Id;
>        public String street, city, state, zip;
>        @Enumerated(EnumType.STRING)
>        public AddressType addressType;
>
>        @ManyToMany(mappedBy="addresses")
>        public Set<Customer> customers;
> }
>
> //Customer.java
>
> import javax.persistence.*;
> import java.util.*;
>
> @Entity
> public class Customer implements java.io.Serializable {
>        @Id @GeneratedValue
>        public long Id;
>        public String name;
>
>        @ManyToMany
>        Set<Address> addresses;
> }
>
> Intuitively, though, AddressType is more relevant to the relationship
> *between* Customer and Address, not solely Address.  The same Address
> could
> have multiple AddressTypes depending on which Customer you're talking
> about
> (for instance, if I have my office address listed as my personal SHIPPING
> address but my employer is also a distinct Customer who uses the same
> address for its BILLING).
>
> Of course, the most obvious solution would be to explicitly define the
> associative entity as a proper domain class:
>
> // CustomerAddress.java
>
> import javax.persistence.*;
>
> @Entity
> public class CustomerAddress implements java.io.Serializable {
>        @Id @GeneratedValue
>        public long Id;
>        public Customer customer;
>        public Address address;
>        public AddressType addressType;
> }
>
>
> ... but then I lose all the advantages of JPA to handle the many-to-many
> relationship.
>
> Ideally, I'd like to do something like this:
>
> // Address.java
>
> import javax.persistence.*;
> import java.util.*;
>
> @Entity
> public class Address implements java.io.Serializable {
>        @Id @GeneratedValue
>        public long Id;
>        public String street, city, state, zip;
>        @Enumerated(EnumType.STRING)
>        public AddressType addressType;
>
>        @ManyToMany(mappedBy="addresses")
>        public Map<Customer, Set<AddressType>> customers;
> }
>
> //Customer.java
>
> import javax.persistence.*;
> import java.util.*;
>
> @Entity
> public class Customer implements java.io.Serializable {
>        @Id @GeneratedValue
>        public long Id;
>        public String name;
>
>        @ManyToMany
>        Map<AddressType, Set<Address>> addresses;
> }
>
>
> As you can see, this pattern would allow me to look up all the Addresses
> of
> a certain AddressType directly from the Customer class.  It would also
> allow
> me to lookup all the AddressTypes associated with a particular Customer
> directly from the Address class.  But it doesn't seem to be covered in the
> general JPA spec, and OpenJPA treats the Map as a BLOB.  Off in SQL-land,
> it's very common to add lookup-table references to associate entities.  It
> seems like there should be a way to do accommodate this in JPA without
> creating a new class.  Any suggestions?
> --
> View this message in context:
> http://www.nabble.com/Using-a-Maps-instead-of-Sets-to-handle-%40ManyToMany--tp14743250p14743250.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

------=_Part_583_6927519.1200061576397--