I would value your expertise on explaining how this JPA ManyToMany code (chapter 5) example below from Java EE 5 with Netbeans 6 book:
What I am not clear about is the following area in create() of CustomerOrderJpaController where there appears to be a lot of re-assigning of entity data back to itself:
( i ) Why is there a need to locate the customer entity with em.getReference() on line 21 when the value has already been found on line 19 (ManyToOne with CustomerOrder owning)?
( ii ) What is the purpose of lines 25 – 27 and especially why is variable itemCollectionItemToAttach being re-assigned to all items found in itself (line 26)? Is it assembling a list of new items to be included into this customerOrder entity object? (ManyToMany – CustomerOrder owning)
( iii ) Why not use em.find() instead of em.getReference()? I thought em.find() is better because it returns NULL when there are no record found and it doesn’t throw an exception?
I am running JDK 1.6.0_23, NB6.9.1, GF 2.1 (Java EE 5) on Windows XP.
Your feedback would be much appreciated to enlightening in this key yet complex technology.
The issues is that the CustomerOrder is a detached object (serialzied possibly). So in order to persist it in the current persistence context its references must be fixed to reference their objects from the current persistence context.
In theory they could just do,
customerOrder = em.merge(customerOrder);
As merge should fix everything up. But perhaps they ran into an issue with merge, or wanted to use persist for some reason.
As to using getReference() instead of find(), they already know the object exists so getReference() can be more efficient as it can just return a stub (of coarse they then access the reference, so it would need to be instantiated anyway).
Thank you very much for filling in the puzzle and enlighten me with how JPA work. You appear to be providing consistent support in this forum in the recent years.
The one liner em.merge(customerOrder) is tempting but must admit that past experiences have resulted in duplicate records being added. So this approach is a long winded way of using em.persist() but will be more reliable instead.
Btw, my intention is to persist Item record through CustomerOrderJpaController.create(). In other word, only uni-directional ManyToMany entity relationship between CustomerOrder & Item is required in this case. Yet the used of mappedBy (line 9 of Item class) as a constraint, to keep both CustomerOrder & Item (foreign keys in CUSTOMERORDER_ITEM) records unique. Moreover, the bi-directional entities setup was not meant to allow persisting from both CustomerOrderJpaController & ItemJpaController but only to keep both sides of data normalized. Can you comment on whether this is the right approach? If not, please suggest an alternative approach to achieve the same objective.
Normally trees don't drive trucks. Does this tiny ad have a license?