openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: composite ID based on "one" side of a bidirectional one-many relationship
Date Tue, 27 Mar 2007 20:18:33 GMT
> 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?

> 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 <provider> element in the
persistence.xml must be obeyed. Only if you do not specify a <provider>
element can the implementation can choose whatever it wants to use.

That said, if you depend on the feature, you are definitely depending on
OpenJPA, and will only be able to port to other JPA implementations that
support the same functionality for relationships as PK fields. But
that's your call as to whether you think that the feature is worth the
lock-in to OpenJPA. Often (and this might not be the case for this
feature), it makes the most sense to go ahead and use vendor-specific
features, but clearly mark them as such, rather than putting yourself
through a bunch of difficulty to work around limitations of the spec.
You'd end up with an application that would take some work to migrate to
a different vendor, but presumably not all that much work, and also the
work involved would essentially just be deferred until you decided it
made sense to do a port.

> i am assuming that that i understood you 
> to say that using and @Id annotation w/ @ManyToOne is not 
> supported by vanilla JPA.

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.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: jeff [mailto:jeffrey.blattman@yahoo.com] 
> Sent: Tuesday, March 27, 2007 1:06 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: composite ID based on "one" side of a 
> bidirectional one-many relationship
> 
> hi patrick, thanks for your response ...
> 
> sorry i forgot to mention that the Book's name is it's ID. 
> maybe that is not realistic but that's the test case i was 
> playing with. yes, i want to use the Book's ID in the Page's 
> composite ID, whatever that may be.
> 
> when i try calling out the Page's book field as an ID, i get 
> an error during enhancement:
>      [java] Exception in thread "main" 
> <4|true|0.9.6-incubating> 
> org.apache.openjpa.util.MetaDataException: The id class 
> specified by type "class com.mycompany.book.Page" does not 
> match the primary key fields of the class.  Make sure your 
> identity class has the same primary keys as your persistent 
> type, that the access types are the same, and if you are 
> getting this error at runtime, that you have your persistent 
> class since last compiling your identity class.
>      [java] FailedObject: book [java.lang.String]
> 
> 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.
> 
> 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? i am assuming that that i understood you 
> to say that using and @Id annotation w/ @ManyToOne is not 
> supported by vanilla JPA.
> 
> 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 ...
> 
> ...
> @Id
> private String bookName;
> ...
> public void setBook(Book b) {
>   this.book = b;
>   this.bookName = b.getName();
> }
> 
> is there a better approach, or is this as good as it gets?
> thanks!
> 
> Patrick Linskey <plinskey@bea.com> wrote: > i want the Page's 
> ID to be based on it's number, and ALSO the 
> > owning Book's name. i could make an ID class for Page, but 
> 
> If you wanted to make the ID be based on it's number and the 
> owning Book
> itself (i.e., not the name), you could do this with OpenJPA, but not
> with vanilla JPA. OpenJPA supports @Id fields on one-to-one and
> many-to-one fields:
> http://incubator.apache.org/openjpa/docs/latest/manual/manual.
> html#ref_g
> uide_pc_oid_entitypk
> 
> Personally, I think thaht using the Book object as part of the PK is
> probably a better idea than using the Book's name, since it seems like
> the Book's name is not unique.
> 
> However, if you really do want to use the Book's name, the only way to
> do so in OpenJPA is to make Book.name the @Id of the Book 
> class, and use
> the syntax in the link I provided above.
> 
> -Patrick
> 
> -- 
> Patrick Linskey
> BEA Systems, Inc. 
> 
> ______________________________________________________________
> _________
> Notice:  This email message, together with any attachments, 
> may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> affiliated
> entities,  that may be confidential,  proprietary,  
> copyrighted  and/or
> legally privileged, and is intended solely for the use of the 
> individual
> or entity named in this message. If you are not the intended 
> recipient,
> and have received this message in error, please immediately 
> return this
> by email and then delete it. 
> 
> > -----Original Message-----
> > From: jeff [mailto:jeffrey.blattman@yahoo.com] 
> > Sent: Tuesday, March 27, 2007 10:08 AM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: composite ID based on "one" side of a bidirectional 
> > one-many relationship
> > 
> > say i have Book and Page classes. a Book has a name and can 
> > also have many Pages. a Page has a number, and a reference to 
> > the owning Book.
> > 
> > i want the Page's ID to be based on it's number, and ALSO the 
> > owning Book's name. i could make an ID class for Page, but 
> > the fields of the ID class need to be simple types, so i 
> > can't map them to the book field in Page ... ?
> > 
> > i did get it to work by adding a bookName field to Page that 
> > gets populated in the setBook() setter, and creating a PageId 
> > that uses the Page's number and the simple bookName field. 
> > 
> > however, this seems wrong, as it results in redundant data 
> > stored in the Page table. for example, the created table for 
> > Page has  NUMBER, BOOKNAME, and BOOK_BOOK_NAME columns, the 
> > latter two of which are always the same. 
> > 
> > i am sure there's a best practice for this. any advice is 
> appreciated.
> > 
> > i have a test case for this i can send if my description is 
> > not obvious, but my last attempt failed apache's spam filter. 
> > 
> > 
> > 
> >  
> > ---------------------------------
> > Don't get soaked.  Take a quick peek at the forecast 
> >  with theYahoo! Search weather shortcut.
> > 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
>  
>  
> ---------------------------------
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message