You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by jeff <je...@yahoo.com> on 2007/03/27 19:08:28 UTC

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.

Re: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Craig L Russell <Cr...@Sun.COM>.
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 <pp...@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!


RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by jeff <je...@yahoo.com>.
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 <pp...@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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Pinaki Poddar <pp...@bea.com>.
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 <pl...@bea.com> 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.

Re: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Abe White <aw...@bea.com>.
> "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?

No, you weren't mistaken.  But as I said, the book field in the  
Page*Id* class must match the pk type of the relation.  Check the  
example in the docs.

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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by jeff <je...@yahoo.com>.
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 <pl...@bea.com> 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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Patrick Linskey <pl...@bea.com>.
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 <pl...@bea.com> 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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by jeff <je...@yahoo.com>.
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 <pl...@bea.com> 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 
> FtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBH
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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Patrick Linskey <pl...@bea.com>.
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 <pl...@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 
> <http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMT
FtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBH
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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by jeff <je...@yahoo.com>.
Patrick Linskey <pl...@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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Patrick Linskey <pl...@bea.com>.
> 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 <pl...@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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by jeff <je...@yahoo.com>.
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 <pl...@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.

RE: composite ID based on "one" side of a bidirectional one-many relationship

Posted by Patrick Linskey <pl...@bea.com>.
> 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.