Re: [eclipselink-users] re move() and a OneToMany mapping with CascadeTy

[James Sutherland <jamesssss@xxxxxxxxx>]

A List could be used instead of a Set to avoid the issue.  I generally find
List more useful than Set, but it depends on your usage and requirements.

Using Object.equals does not have any issues with EclipseLink.  Your
application code may have dependencies on it.  JPA manages object identity
within the persistence context, but if you mix managed and detached objects,
then you could have two copies of the same object that are not equal, which
you will need to managed (although having two copies of the same object in
the same context is not generally a good idea).



patric-7 wrote:
> 
> Done, see:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=338393
> 
> Btw: Which Collection type would you recommend for ManyToOne relations?
> 
> What are the drawbacks when relying on Object.equals() /
> Object.hashCode()?
> Will this cause problems, e.g.
> - when using weaving?
> - when putting an attached and detached entity of the same physical  
> record to the IndirectSet?
> - in other situations?
> 
> Thank you and best regards,
> Patric
> 
> Zitat von James Sutherland <jamesssss@xxxxxxxxx>:
> 
>>
>> Interesting.  Please log a bug that clear() in IndirectSet should call
>> clear() after recording the removal of the objects in-case of an identity
>> change.
>>
>> Changing your objects hashCode after putting it into a Set or Map is not
>> a
>> good idea in general.  You should either ensure the Id is assigned before
>> putting it into the Set, or rely on Object equals/hashCode instead of
>> your
>> Id.
>>
>>
>>
>> patric-7 wrote:
>>>
>>> The problem is that the hashCode() of my entity changes during the
>>> transaction
>>> resulting in that the entity is unequal to the backup clone.
>>> (so the entity is changed and removed at the same time)
>>>
>>> I am using the "business-Id" as the identity of an entity for equals()
>>> and hashCode().
>>>
>>> As a consequence that the IndirectSet delegate cannot find the
>>> hashCode in the approriate hash bucket when calling Iterator.remove().
>>>
>>> I have two questions:
>>>
>>> 1. Shouldn't IndirectSet.clear() rely on the delegate's clear() method
>>> instead of removing all elements using an iterator which fails in the
>>> above mentioned case.
>>> Currently IndirectSet seems to violate the Set interface contract
>>> which guarantees that clear() will remove all objects.
>>>
>>> 2. What is recommended/best way for implementing equals() / hashCode()
>>> in JPA/EclipseLink entities?
>>> I can see three options:
>>> a) business-ID (all non-technical fields, without PK and FKs)
>>> b) primary key
>>> c) rely on Object.equals() / Object.hashCode()
>>>
>>> Thank you and best regards,
>>>
>>> Patric
> 
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance 
-- 
View this message in context: http://old.nabble.com/remove%28%29-and-a-OneToMany-mapping-with-CascadeType.PERSIST-tp30785713p31107125.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.