StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I personally already used all of these three stategies in different projects. An I must say that option 1 is in my opinion the most practicable in a real life app. A made the experience breaking hashCode()/equals() conformity leads to many crazy bugs as you will every time end up in situations where result of equality changes after an entity has been added to a collection.</p> <p>But there are further options (also with their pros and cons):</p> <hr> <p>a) hashCode/equals based on a set of <strong>immutable</strong>, <strong>not null</strong>, <strong>constructor assigned</strong>, fields</p> <p>(+) all three criterias are guaranteed</p> <p>(-) field values must be available to create a new instance</p> <p>(-) complicate handling if you must change one of then</p> <hr> <p>b) hashCode/equals based on primary key that is assigned by application (in constructor) instead of JPA</p> <p>(+) all three criterias are guaranteed</p> <p>(-) you cannot take advantage of simple reliable ID generation stategies like DB sequences</p> <p>(-) complicated if new entities are created in a distributed environment (client/server) or app server cluster</p> <hr> <p>c) hashCode/equals based on a <a href="http://de.wikipedia.org/wiki/UUID" rel="noreferrer">UUID</a> assigned by constructor of entity</p> <p>(+) all three criterias are guaranteed</p> <p>(-) overhead of UUID generation</p> <p>(-) may be a little risk that twice the same UUID is used, depending on algorythm used (may be detected by an unique index on DB)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload