Let’s assume we have a Book class that looks like this:
@CompileStatic
class Book {
String name
String author
Float price
}
Within our app we have several places where a widget is presented to the end-user, such as an API that drives a mobile app, an API that drives a single-page-application (like react/vue/etc), or even something rendered server-side like a GSP.
The data is represented well, and the customer is happy, but now there’s a business rule that states that all books should be presented sorted alphabetically. We can do this several ways:
- Sort it in a controller
- Sort it in the view itself
- (Edit) Specify the sort order in the domain class
Edit: If you are using a data source that supports it, you can specify sort columns and order directly in the mapping
closure. The point of this post still stands outside the context of GORM though. If you have a list of any POGO you could be affected.
If we sort it in the controller it looks like this:
@ReadOnly
def index() {
// old code
//respond Book.list()
// new code to sort by name
respond Book.list().sort { it.name }
}
This will work, but some developers may want to record the fact that a book’s “natural order” is that of being sorted by name. In other words, the fact is stored on the domain itself of how it should be sorted. Let’s impliment this using java’s compareTo
method:
@CompileStatic
class Book implements Comparable<Book> {
String name
String author
Float price
@Override
int compareTo(Book other) {
// Sort by name ascending
return this.name <=> other.name
}
}
Now our controller method looks like this:
@ReadOnly
def index() {
// old code
//respond Book.list()
// new code to sort, this time by using the pre-defined "natural order"
respond Book.list().sort()
}
THIS HAS A VERY SERIOUS SIDE-EFFECT
The above is not an ideal solution, and it’s best illustrated with a concrete example.
def book1 = new Book(name: 'The Gadfly', author: "Ethel Voynich", price: 19.95)
def book2 = new Book(name: 'The Gadfly', author: "Johnny Copycat", price: 9.95)
assert book1 != book2 // THIS FAILS!!! GROOVY THINKS THEY ARE EQUAL!
It’s a bit worrisome that the two books are equal. This is clearly not the case.
What’s happening?
I’ll get to the technical reasons in a minute, but based on observation, it appears that it’s only checking the name
field of our class for equality, and stopping there.
At this point all we know is the language is incorrectly interpreting the idea of equality between two books. It thinks that just because the book names match, that the book objects must be equal.
Let’s try to fix this
We introduced natrual ordering, but it has clearly affected the definition of equality for books. Therefore let’s try to rectify this situation be defining an equals
method so there’s no confusion:
@CompileStatic
class Book implements Comparable<Book> {
String name
String author
Float price
@Override
int compareTo(Book other) {
// Sort by name ascending
return this.name <=> other.name
}
@Override
boolean equals(Book other) {
this.name == other.name &&
this.author == other.author &&
this.price == other.price
}
}
Now we’re expressing the idea that a book can only equal another book if the name, author, and price match.
Let’s test this:
def book1 = new Book(name: 'The Gadfly', author: "Ethel Voynich", price: 19.95)
def book2 = new Book(name: 'The Gadfly', author: "Johnny Copycat", price: 9.95)
assert !book1.equals(book2) // This passes, we should be ok
assert book1 != book2 // THIS STILL FAILS!!! WHY IS THIS?!
Why didn’t defining equals
fix ==
?
After all, doesn’t the ==
operator just delegate to the equals
method in groovy?
Let’s look closer at the documentation: http://docs.groovy-lang.org/latest/html/documentation/index.html#_behaviour_of_code_code
In Java == means equality of primitive types or identity for objects. In Groovy == translates to a.compareTo(b)==0, if they are Comparable, and a.equals(b) otherwise. To check for identity, there is is. E.g. a.is(b).
Oof. This really hinders our ability to define a natural order. Even if we define equals
, it will be ignored if our class implements Comparable
.
What is the solution?
Let’s look at the Java recommendations for the Comparable
interface: https://docs.oracle.com/javase/7/docs/api/java/lang/Comparable.html
It is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave “strangely” when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.
In groovy, if we follow this recommendataion everything works fine. So let’s make compareTo
consistent with equals
:
@CompileStatic
class Book implements Comparable<Book> {
String name
String author
Float price
@Override
int compareTo(Book other) {
// Sort by name ascending
int cmp = this.name <=> other.name
// Then sort by author, then price
if (!cmp) {
cmp = this.author <=> other.author
}
if (!cmp) {
cmp = this.price <=> other.price
}
return cmp
}
@Override
boolean equals(Book other) {
this.name == other.name &&
this.author == other.author &&
this.price == other.price
}
}
Now when we call compareTo
on another instance it will only return 0
when the instances are equal.
def book1 = new Book(name: 'The Gadfly', author: "Ethel Voynich", price: 19.95)
def book2 = new Book(name: 'The Gadfly', author: "Johnny Copycat", price: 9.95)
assert book1.compareTo(book2) != 0 // passes
assert !book1.equals(book2) // passes
assert book1 != book2 // passes
That’s too much code. Is there a better way?
We can use Groovy’s built-in transforms to achieve the same result with far less code:
@CompileStatic
@Sortable(includes = ['name', 'author', 'price'])
@EqualsAndHashCode // Not required, but here for completeness
class Book {
String name
String author
Float price
}
The @Sortable
annotation implements the Comparable
interface for us. Furthermore, if the includes
argument is used it will check the fields in the order they are listed.
I’ve listed the @EqualsAndHashCode
transformation here as well to generate those methods, simply because we had them in the above snippets. They aren’t strictly necessary to make our test pass since Groovy will only look at compareTo
, but I think that documenting that we are defining equality somewhere in this class is important, and this is a way to achieve that.
Just a word of caution: be sure to include all fields in the @Sortable
includes list. Otherwise the natural order of the class becomes inconsistent with the equality.
What if I want to use a custom equals
method?
I can’t think of a reason you would need this, but it should be able to do something like this:
@Override
boolean equals(Book other) {
// custom definition of equality
// ...
return equalsObject(other)
}
@Override
int compareTo(Book other) {
if (this.equals(other)) {
return 0
} else {
// Normal sort logic from above:
// Sort by name ascending
int cmp = this.name <=> other.name
// Then sort by author, then price
if (!cmp) {
cmp = this.author <=> other.author
}
if (!cmp) {
cmp = this.price <=> other.price
}
return cmp
}
}
Remember, the key is to ensure that the natural order is consistent with equality.
I hope this helps someone out!
Top comments (0)