> Assuming I'm still on solid ground, that means that I
> need to define an entity for the join table. No
> problem; I've done this before. Let's call it a
> PartyPostalAddressBinding. So far so good. This
> entity never shows up in the domain layer; it exists
> only as a by-product of JPA usage.
>
> My next problem is that I would like it to have a
> primary key that (obviously, I hope) consists of the
> type and the partyID. So, my second question: how do
> I define my PartyPostalAddressBinding to have a
> compound primary key whose component parts are
> themselves JPA relationships (ManyToOne for each
> side--many PartyPostalAddressBindings may have one
> Party, and many PartyPostalAddressBindings may have
> one PostalAddress)? It appears that IdClass won't
> work here, but I may be wrong about that.
>
I'd define the pk on partyId and postalAddressId, b/c these values
identify the relationship btw Party and PostalAddress. The type would
be the only non-pk property in PartyPostalAddressBinding. The
relationships would be defined as follows:
Party <-1---M-> PartyPostalAddressBinding <-M---1-> PostalAddress
This is an overlapping pk/fk situation. In this case, you'd need to
map PartyPostalAddressBinding's relationship fields as
updatable=false.
> (If I have to give up on that and simply use a
> (redundant) serial primary key via an @Id annotation,
> that is not a huge deal; I'll just make sure that
> there's an appropriate unique constraint on partyID
> and type.)
>
> Lastly, am I correct in saying that no usage of
> MapKey will get me what I want here? Or rather that
> the only way a MapKey annotation would help is if I
> could somehow solve the compound primary key problem,
> and could pass an instance of either my @IdClass
> or...or...my @EmbeddedClass? as the key?
>
You're correct, MapKey can not be used.
> Finally, if that's all true, then it seems to me I
> have no choice but to say that a PartyEntity has a
> @OneToMany relationship with
> PartyPostalAddressBinding, and that I will need to
> roll my own map access. Is that correct?
>
You can have a persistent collection field or property in Party, and
someDude.getPostalAddress(preferred)
would be implemented as a business method first looking up right entry
in the collection, and returning it's associated PostalAddress. The
OrderBy annotation could be used to simplify the search. If needed, the
PostalAddress side could be implemented the same way.
-- markus.
[Message sent by forum member 'mf125085' (mf125085)]
http://forums.java.net/jive/thread.jspa?messageID=215454