EJB3: One-to-one relationships and auto-generation of primary key values...

Question

Dear Forum,
I'm relatively new to JEE, and while I've so far enjoyed the convenience of EJB3 for most things, it seems that I have a corner case that can not be handled by the entity manager.
First, here's a quick mockup of my entities:
    Gallery
            |
            -- [1] -------[1] ----> Author
            |
            -- [1] -------[M] ---> Photo
                                              |
                                              -- [1] ------ [1] -> PhotoImage
                                                                                 |
                                                                                 -- [1] ------ [1] -> IPTCData
                                                                                 |
                                                                                 -- [1] ------ [1] -> EXIFDataI also have a remote, stateless session bean that does nothing more than persist()/merge()/remove() and locate (through find() and a few custom queries) my Gallery and Photo instances.
Now, the abridged version of my problem is this: when I persist a Photo, it naturally gets its primary key generated (I used @Id and @GeneratedValue). However, for some reason none of the other dependent entities inherit Photo's primary key value. In my client, I create a new Gallery locally and then persist it. I then create new Photo, PhotoImage, IPTCData and EXIFData instances. I add the IPTCData and EXIFData instances to PhotoImage (there are PhotoImage methods for adding those); then I add the PhotoImage instance to Photo (again, Photo has a setter for adding a PhotoImage). Then, I persist the Photo.
--- Aside: ------------
I've set up my relationships using annotations like @OneToMany (Gallery references a Collection of Photos), and @OneToOne (Photo's primary key references PhotoImage's primary key; PhotoImage's primary key references the primary keys of IPTCData and EXIFData). I've also added @JoinColumn annotations where necessary.
Finally, I get the Gallery instance's Photo collection (public Collection<Photo> getPhotos()), I add the Photo to the collection, and I add the Photo collection BACK to the Gallery (public void setPhotos(Collection<Photo>)).
At this point, the Gallery should have all of my entities contained inside of itself. However, when I persist the Gallery at this point, all of the entities show up in the database, but none of the primary keys get inherited. Photo's primary key gets generated automatically, of course, but the rest have zero (0) as their PK values. I had wanted, for example, IPTCData to get the value of Photo.id.
I had assumed that the entity manager would persist everything for me provided that I told it, through my annotations, about which entities relate to which. Does persistence only work in the direction of retrieval? That is, does the entity manager only do its thing when fetching (versus setting) data when there is more than 1 object in the graph? I can't believe that it can't, otherwise we'd all be ditching it and going back to straight SQL to do our work.
Thus, I HAVE to be doing something wrong, or else omitting to do something right.
I've made other incarnations of the above setup, and none of them have worked perfectly. I've even set up foreign key constraints in the database, but I had my share of unresolvable problems there, too.
So I guess my big question with all of this is: when you have a deeply nested graph of objects, can the entity manager figure everything out and persist all of the objects correctly and with the right values? If not, boo. If so, how does one accomplish this?
I know that I could persist each and every entity separately in my client code, but I wanted to have a natural-looking way of piecing all of my entities together. More specifically, I could persist IPTCData explicitly; however, I want to be able to add everything to a Photo and only persist the Photo itself, with the idea that all of the objects and sub-objects would be persisted automagically.
Is this possible? Or have I bought into a pipe dream with the guarantee of the proverbial magic bullet?
Thanks to everyone in advance for his/her input.
Regards,
Michael

Answer 1

Daniel,
Late last night I found the solution to my problem. And you're right, it had everything to do with which side is wired to which. I got confused about which side to consider the "owning" side, since one can look at it from the perspective of the database or the application.
Interestingly, the first 2 lines of your example code match my client code almost verbatim: First, I create a new Gallery (or else I get an existing one). I then create a new Photo and then add it to the Gallery's collection using add(). I then persist the Gallery. My session bean internally calls EntityManager.merge(gallery). How it differs from your example, though, is in the fact that, on an application level, a Photo has no knowledge whatsoever of a Gallery. Which is to say that my Photo class does not have a 'getGallery()' method. Somehow, Hibernate is able to figure it all out and still update Photo's 'parentIdRef' column in the database. My logs show that Hibernate issues a SQL UPDATE on the Photo after both a Gallery and a Photo have been created. It sets the Photo's 'parentIdRef' column to the primary key value of the owning Gallery.
Getting back to the matter, my problem was not with being able to map a Photo to a Gallery; rather, I was unable to add a PhotoImage to a Photo and have the relationship get correctly mapped in the database. The relationship between a Photo and a Gallery is many-to-one: there can be many Photo objects inside of a Gallery. In the database, a Photo row contains a 'parentIdRef' column whose value is that of a Gallery's primary key. I used @OneToMany on the Gallery, since a Gallery is, from an application perspective, the "owning" side, even though it's only the Photo that knows who it's referring to since only IT contains the 'parentIdRef' column in the database.
I tried setting up the relationship between a PhotoImage and a Photo in the same manner, with the PhotoImage having a 'parentIdRef' column and referring to a Photo's primary key. I had annotated the Photo's getPhotoImage() method with @OneToOne, along with an appropriate @JoinColumn.
It was THIS part that I had backwards. With a @OneToMany relationship, the child refers back to the parent --- it can be no other way. However, with a @OneToOne relationship, the owner refers to the child.
So, to make a long story short, all I had to do was create extra database columns for Photo. Those columns refer to the primary keys of PhotoImage, EXIFData and IPTCData. Concretely, for example, Photo.photoImageIdRef references PhotoImage.id. And so on and so forth.
The only negative side-effect of this is that my database-level foreign key constraints are now broken, since Hibernate wants to persist PhotoImage, EXIFData and IPTCData before it persists Photo.
I have to investigate more deeply the 'cascade=...' option of the @OneToOne annotation in order to find out it relates, if at all, to a database-level cascade.
Anyway, thanks for the reply. It seems that you had a very good idea about what my problem was. I would have posted the fact that I had resolved the problem last night, except that it was too late and I was heading to bed. If you still want the Duke points, let me know. I don't currently know the rules about if, when and to whom I should issue points in cases like these when I've already solved the problem.
Regards,
Michael