openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jeff <jeffrey.blatt...@yahoo.com>
Subject RE: composite ID based on "one" side of a bidirectional one-many relationship
Date Tue, 27 Mar 2007 20:42:05 GMT
Patrick Linskey <plinskey@bea.com> wrote: > my ID class has a book field, and getters
and setters for it 
> to match Page's book field. i wonder about the last line 
> where it says "java.lang.String". that seems odd.

Can you post your Book and Page classes and the Page's IdClass?
attached. i keep trying to attach the entire project as a zip, but apache's spam filter keeps
dropping it. let me know i could send to you directly.
> so, regardless, even if that did work, correct me if i am 
> wrong, but it'd be a really bad idea to depend on openjpa 
> specifics, because my app doesn't get to choose the JPA 
> implementation, it has to use whatever the java ee container 
> gives it ... right?

No -- a Java EE 5 container *must* allow you to specify your persistence
provider. Whatever you put in the 
 element in the
persistence.xml must be obeyed. Only if you do not specify a 

element can the implementation can choose whatever it wants to use.


yes, duh. sorry.











Correct.

> so, assuming i do need to accomplish this, is there a best 
> practice? as i mentioned, what i did to make it work was make 
> the Page's composite ID incorporate the Book's ID by adding a 
> "derived" bookName field to Page, like ...

You could add a private bookName field that has no external mutators or
accessors, and create a @PreStore callback that copies the value from
the related Book into the field. That would do a decent job of isolating
the artifact from the rest of your app.


yes, that works.
 
---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
Mime
View raw message