openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: composite ID based on "one" side of a bidirectional one-many relationship
Date Mon, 02 Apr 2007 01:01:49 GMT
Hi Jeff,

The reason that this is done is so you can create an instance of the  
PageId class without having a persistent (or detached) instance of  
Book. The way it works now, if you have the id of the Book you can  
construct an instance of the PageId by also supplying the page number.

If the types matched, you would need to have an instance of Book that  
had the proper id field set before you could create an instance of  
PageId. Which would mean that you might have to go to the database  
twice to get a Page (once to get the Book and another to get the Page).

Another alternative if you want to avoid this "confusion" is to have  
the Page mapped with a String bookId and int number. But that would  
mean mapping the bookId column to both the Book relationship and to  
the primary key. Which has its own set of issues.

Hope this makes sense. It was done deliberately.

Craig

On Mar 29, 2007, at 9:02 AM, jeff wrote:

> thanks pinaki, now i get it :)
>
> i must say though that these are confusing semantics. JPA wants me  
> to name the fields and mutators the same between the Page and  
> PageId class, but for them to be different types. imagine an object  
> model with two classes and two methods,
>
> Foo.getBlah()
> Bar.getBlah()
>
> where Foo.getBlah() returns a String, and Bar.getBlah() returns an  
> int. not exactly intuitive to the user of such an API.
>
> anyway :)
>
> Pinaki Poddar <ppoddar@bea.com> wrote: Page can have a primary key  
> field type of "Book".
>
> @IdClass(com.mycompany.book.PageId.class)
> @Entity
> public class Page {
>   @Id
>   int number;
>
>   @Id
>   @ManyToOne
>   private Book book;
> }
>
> public class PageId {
>    int number;
>    String book; // the type "String" must match the type of primary  
> key
> used in Book.java
>                          // the name of the variable "book" must match
> the name of the variable in Page class.
> }
>
> public class Book {
>    @Id
>    String title;
> }
>
>
>
>
> Pinaki Poddar
> BEA Systems
> 415.402.7317
>
>
> -----Original Message-----
> From: jeff [mailto:jeffrey.blattman@yahoo.com]
> Sent: Wednesday, March 28, 2007 4:35 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: RE: composite ID based on "one" side of a bidirectional
> one-many relationship
>
> hi,
>
> abe closed this with the reasoning ...
>
> "the book field in the PageId class must be of type String to match  
> the
> primary key field type of Book"
>
> was i mistaken when i understood you to say that Page could have a PK
> field of type Book? if not, very sorry for all the confusion.
>
> or were you just saying that open JPA allowed the PK field to be a
> ManyToOne relationship?
>
> p.s., it's issue #191
> https://issues.apache.org/jira/browse/OPENJPA-191
>
> Patrick Linskey
>  wrote: Yes, please do. It looks like
> your code should work.
>
> -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: Wednesday, March 28, 2007 10:31 AM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: RE: composite ID based on "one" side of a bidirectional
>> one-many relationship
>>
>> yes, i see the problem w/ the attached classes, and with a completely
>> different model where i am trying to accomplish the same thing.
>>
>> should i file a bug? i can attach the test case there.
>>
>> Patrick Linskey
>  wrote: Are you still
>> seeing that same problem with the code that you attached?
>>
>> -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:42 PM
>>> To: open-jpa-dev@incubator.apache.org
>>> Subject: RE: composite ID based on "one" side of a bidirectional
>>> one-many relationship
>>>
>>> Patrick Linskey
>>  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
>>>
>> FtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0
>> YWdsaW5lBH
>> NsawNxMS0wNw-->  to > find flight and hotel bargains.
>>>
>>
>> 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.
>>
>>
>>
>>
>> ---------------------------------
>> Food fight? Enjoy some healthy debate
>> in the Yahoo! Answers Food & Drink Q&A.
>>
>
> 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.
>
>
>
>
> ---------------------------------
> Bored stiff? Loosen up...
> Download and play hundreds of games for free on Yahoo! Games.
>
> 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.
>
>
>
>
> ---------------------------------
> Sucker-punch spam with award-winning protection.
>  Try the free Yahoo! Mail Beta.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message