15

I hit a problem when writing tests for a database application using JPA2 and EclipseLink:

I add some entity to a database, retrieve it later and want to compare it to an instance which has the values I expect to confirm that the addition worked as I intended.

First I wrote something like

assertEquals(expResult, dbResult);

which failed, because I can't really know the value of id field, which is generated by the database and therefore dbResult differs from expResult which I created with new and populated manually.

I see two options:

  • Either I remove the id field from equals and hashCode so that the comparison is only based on the "real values". I don't know if this causes problems in the database or elsewhere, though.

  • Or I write my tests to explicitly check every field except id manually.

What should I do?

soc
  • 27,983
  • 20
  • 111
  • 215

4 Answers4

15

You might find a lot of controversy about this one. My stance is that you absolutely don't use a database primary key for anything in your application. It should be completely invisible. Identify your objects in your application by some other property or combination of properties.

On the "testing persistence operations" front, what you really want is probably to check that the fields were saved and loaded correctly and maybe that the primary key got assigned some value when you saved it. This probably isn't a job for the equals method at all.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
8

Relying on database generated Ids in your equals and hashCode implementation is not advisable. You ought to rely on the truly unique/semi-unique attributes of your classes in checking for equality, and in generating the hashcode values. The Hibernate documentation has an extensive page that discusses this, and the facts therein are applicable to more or less every JPA provider.

The underlying reason for using business keys over database generated values in your equals and hashCode implementation is that the JPA provider must actually issue a SELECT after persisting the entity in the database. If you compare objects using the database generated Ids, then you will end up having an equality test that fails in the following scenarios:

  • If E1 and E2 are entities of class E (that verifies equality using database generated Ids), then if E1 and E2 will be equal if they haven't been stored in the database yet. This is not what you want, especially if want to store E1 and E2 in some Set before persistence. This is worse if the attributes of E1 and E2 possess different values; the equals implementation would prevent two significantly different entities from being added to a Set, and the hashCode implementation will give you a O(n) lookup time when entities are looked up from a HashMap using the primary key.
  • If E1 is a managed entity that has been persisted, and E2 is an entity that has not been persisted, then the equality test would deem that E1 != E2 in the scenario where all the attribute values of E1 and E2 (except for the Ids) are similar. Again, this is probably not what you want, especially if you want to avoid duplicate entities in the database that differ only in their database generated Ids.

The equals and hashCode implementations therefore ought to use business keys, in order to exhibit consistent behavior for both persisted and unpersisted entities.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
7

From the book Hibernate in Action, its recommended to defined a business key and test equality on that. A business key is "a property, or some combination of properties, that is unique for each instance with the same database identity." In other areas it says to not use the id as one of those properties, and don't use values in collections.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
1

I would write my test to explicitly check for fields. To make this easy, before performing the assertEqual test, I will set the id of both the expected and actual result to the same predefined value and then use the normal equals method.

Removing ID from equals is not justifiable, just because testing is slightly difficult. You are foregoing serious performance benefits and also code integrity.

uncaught_exceptions
  • 21,712
  • 4
  • 41
  • 48
  • What are the performance and integrity problems associated with not considering the id? Wouldn't checking for a database id be the same thing as using `Object#hashCode` in my `equals` and `hashCode` methods? – soc Sep 07 '11 at 22:19
  • Lets say that you have project entities. You have to send a list of unique projects from your service layer. Now there is a possibility that a faulty equals will consider two unique records as the same record. Having ID reduces this problem. Also the solution is not scalable, we have to update our equals method, if we decide to change what makes an object unique. – uncaught_exceptions Sep 08 '11 at 01:50
  • Having an ID that is guaranteed to be unique is a perfect for hashing. We are guaranteed to avoid Hash collisions. Otherwise, the quality of hashing becomes a function of whether, we considered all attributes that should be unique and ignored all attributes that are not. – uncaught_exceptions Sep 08 '11 at 01:52
  • We have a different (from the database ID) "business" ID which is unique. Does this solve the problem? – soc Sep 08 '11 at 13:32
  • Yes,I think so, as long as, it is guaranteed to be unique. (Sorry for all the typos in my previous comments. My excuse is sleep deprivation :) ). – uncaught_exceptions Sep 08 '11 at 13:52