Briefly, that's what I've always done (stored it as just another entity, and managed the map access myself).
I can't put type on PostalAddress, because it is not a logical property of a PostalAddress. It is indeed a logical property of a party's relationship [i]to[/i] that address. So it has to live in the binding/join table.
What's interesting is that the overarching pattern here is something like this: I want to do a join table, but I want it to have one piece of extra state, and it just so happens that that bit of extra state is the key used by HashMap clients to look up what's in there. What needs to be supplied at the database end of things, however, is not just the HashMap key (the type in this case) but the PartyID in question--which on the Java side is implicit--it's the caller who's asking for a PostalAddress-keyed-by-a-type.
JPA handles the common case of put-an-object-in-a-map-and-index-it-by-its-primary-key (that's what MapKey is for). It would be neat if it also handled non-primary-key access.
Laird
[Message sent by forum member 'ljnelson' (ljnelson)]
http://forums.java.net/jive/thread.jspa?messageID=215576