EJB 3 Required to Override equals & hashCode

[ddurst]

Is it required that I override equals & hashCode for EJB 3 POJOs?

[alrubinger]

Nope.

"EJB3 Core Specification, 4.7.3" wrote:
The container provider is responsible for providing the implementation of the equals and hashCode
methods for the business interface, in conformance with the requirements of section 3.6.5.

S,
ALR

[mazz]

You are about to open a pandora's box :)

Google "hashCode" and "equals" as it relates to EJB3 and Hibernate.

You'll find the answer to this question isn't as simple as you first think.

[mazz]

A good page describing the issues I alluded to can be found on the Hibernate wiki at:

http://www.hibernate.org/109.html

[alrubinger]

My response was in relation to Session Beans only. :)

S,
ALR

[ddurst]

Wow!
I am now only more confused than I was before.
This issue stems from a previous post that I made about my OneToMany
relationships only saving one child.

As I determined it was because my IDE (NetBeans) was created Override methods for equals() and hashCode().... So I asked this question.

Based on ALRubingers response I went ahead and removed these methods
from my POJOs and have experienced no adverse side affects in my application.

I have read http://www.hibernate.org/109.html

Which clarified very little for me besides that if I do override these methods I should use a "Business Key". This idea for some entities tweaks my head a little bit, as I see no "Business Key" for a Entity such as a Order Line.

Can someone give me a example of a relationship like Order -> OrderLine
in which equals() and hashCode() are overried properly.

[waynebaylor]

go for logical equality, so if your entity has three fields:

@Id
@GeneratedValue
private int id;

private String firstName;

private String lastName;

then equals/hashCode should be based on first/lastName and not id.

[ddurst]

go for logical equality, so if your entity has three fields:
Code:

@Id
@GeneratedValue
private int id;
private String firstName;
private String lastName;

then equals/hashCode should be based on first/lastName and not id.

I understand this concept as you have put forth. That being that a firstName & lastName has some uniqueness.
This issue occurs in my mind when you have 2 Joe Smiths.
These to object are then considered equal when they may not actually
be EQUAL in reality. So to then you would say add SSN or some other
unique. Which in all reality replaces the Primary key. This works for
objects with such unique identifier.

Unfortunately with objects such as a Order Line where the structure are as follows:

 @Id
 @GeneratedValue(strategy = GenerationType.SEQUENCE)
 private Long id;
 private String lineStatus = OrderLine.SHIP_WHEN_COMP;
 @Temporal(TemporalType.TIMESTAMP)
 private Calendar requiredDate;
 private LineQuantity quantity;
 @Embedded
 private PriceCost priceCost;
 @OneToOne(cascade = CascadeType.ALL)
 private Item item;
 @ManyToOne
 @JoinColumn(name="parentOrder")
 private Order parentOrder;

Business unique identifiers do not exist.

Two order lines where all attribute values are equal can exist on the same parent order.

Does anyone have a example of how to resolve THIS specific issue?