Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Rules for equals and hashcode methods for an entity(JPA best practices)
Rules for equals and hashcode methods for an entity [message #508864] Wed, 20 January 2010 10:18 Go to next message
Daniel Le Berre is currently offline Daniel Le Berre
Messages: 82
Registered: July 2009
Member
I cannot find on EclipseLink web site nor on JPA 2.0 specification if an entity has specific requirements regarding the hashcode and equals methods.

Should those methods be overrided to take into account business attributes? rely only on the primary key field?

I know that some guidelines are provided for hibernate: https://www.hibernate.org/109.html

What is the best practice for eclipselink?
Re: Rules for equals and hashcode methods for an entity [message #508875 is a reply to message #508864] Wed, 20 January 2010 05:50 Go to previous messageGo to next message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
On 2010-01-20 16:18, Daniel Le Berre wrote:
> I cannot find on EclipseLink web site nor on JPA 2.0 specification if an
> entity has specific requirements regarding the hashcode and equals methods.
>
> Should those methods be overrided to take into account business
> attributes? rely only on the primary key field?
>
> I know that some guidelines are provided for hibernate:
> https://www.hibernate.org/109.html
>
> What is the best practice for eclipselink?

After some serious real world issues during the last year and during migration to higher versions of Eclipselink, this seems to work for me now:
- check on PK and version for speed
- if these are not available check on all simple and one-to-many properties (so no collections)

However Eclipselink has changed some things in the assignment of Id's which gave me troubles in JPA events. I'm using Eclipselink events now.

Code example:

public boolean equals(Object o)
{
if (o == null) return false;
if (this == o) return true;
if (!(o instanceof nl.reinders.bm.License)) return false;
nl.reinders.bm.License lOther = (nl.reinders.bm.License)o;
boolean lEqual = true;
// if a primary key is defined, we use that (this is very quick)
if ( this.iLicensenr != null && lOther.iLicensenr != null
&& this.iLazylock != null && lOther.iLazylock != null
)
{
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iLicensenr, lOther.iLicensenr );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iLazylock, lOther.iLazylock );
}
// otherwise we need to do a compare on featured properties
else
{
// simple properties
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iLicensenr, lOther.iLicensenr );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iStartdate, lOther.iStartdate );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iEnddate, lOther.iEnddate );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iRoyaltyPercentage, lOther.iRoyaltyPercentage );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iExternalNumber, lOther.iExternalNumber );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iLazylock, lOther.iLazylock );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iDwhmodified, lOther.iDwhmodified );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iDwhby, lOther.iDwhby );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iTitle, lOther.iTitle );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iAdvance, lOther.iAdvance );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iGuarantee, lOther.iGuarantee );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iSellOff, lOther.iSellOff );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iRequiredSamples, lOther.iRequiredSamples );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iGeoLimit, lOther.iGeoLimit );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iRemark, lOther.iRemark );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iReport, lOther.iReport );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iPaymentStartAmount, lOther.iPaymentStartAmount );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iPaymentStartDate, lOther.iPaymentStartDate );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iCopyright, lOther.iCopyright );
// one properties
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iReindersContact, lOther.iReindersContact );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iSalesContact, lOther.iSalesContact );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iRoyaltiesContact, lOther.iRoyaltiesContact );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iArtworkContact, lOther.iArtworkContact );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iCurrency, lOther.iCurrency );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iLicensePaymentengine, lOther.iLicensePaymentengine );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iRelation, lOther.iRelation );
if (lEqual) lEqual &= nl.knowledgeplaza.util.ObjectUtil.equals( this.iReindersRelation, lOther.iReindersRelation );
}
return lEqual;
}
Re: Rules for equals and hashcode methods for an entity [message #509198 is a reply to message #508864] Thu, 21 January 2010 11:26 Go to previous message
James Sutherland is currently offline James Sutherland
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

EclipseLink has no specific requirements on equals and hashCode. Internally we always use object identity (IdentityHashMaps), so should have no dependency on these.

Your application and object model may have dependency on these, so you should always implement them correctly as Java requires.

Avoid using attributes that change in your equals/hashCode, because if you object's hash changes, and was used inside a HashMap or HashSet in your application, then it may not be able to be found in that collection using the new hash.


James : Wiki : Book : Blog : Twitter
Re: Rules for equals and hashcode methods for an entity [message #509201 is a reply to message #509198] Thu, 21 January 2010 06:34 Go to previous message
Tom Eugelink is currently offline Tom Eugelink
Messages: 806
Registered: July 2009
Senior Member
> Avoid using attributes that change in your equals/hashCode, because if
> you object's hash changes, and was used inside a HashMap or HashSet in
> your application, then it may not be able to be found in that collection
> using the new hash.

Interesting point... But since entities are by essence not immutable, that is not easy to do. Only a PK would be candidate then.

Tom
Previous Topic:problem with persistence unit
Next Topic:@ElementCollection from embeddable object
Goto Forum:
  


Current Time: Sat Aug 02 00:57:43 EDT 2014

Powered by FUDForum. Page generated in 0.01550 seconds