Gunnar has I had a long discussion and disagreement on the behavior of Option
in Hibernate OGM that we could not resolve. We would like your feedback.
I did design Option to represent three key concepts:
- an option family - for example named query
- an option per se - for example the combination of the named query family and
the query name
- an option value - for example the named query value (the HQL)
These notions used to be separated in a previous incarnation but for the sake
of simplification, we decided to merge option and option value.
So when I designed Option I added the notion of option identifier that combined
with an option class (the family) would uniquely identify an option. This
notion is represented by getOptionIdentifier() which is used by equals() and
hashCode(). The idea is that an Option instance uniquely identifies an option
and that we could detect when a user tries to define the same option several
times (with or without different values).
We have two kinds of options:
- generic options like named query that required an additional key to be
uniquely identified
- unique options like show_sql where the option family and the option are one
and the same thing
In the unique option case, a UniqueOption subclass force the implementation of
getOptionIdentifier so that equals / hashCode are true if the same option /
option family are requested.
A goal of getOptionIdentifier() was to free the Option implementor from
thinking too much about the equals() / hashCode implementation and just focus
on the option identity.
Now Gunnar had a concern when he experimented with unique options
class ShowSql extends UniqueOption {
private String value;
public ShowSql(String value) {
this.value = value;
}
public static ShowSql TRUE = new ShowSql("true");
public static ShowSql FALSE = new ShowSql("false");
}
In this situation, ShowSql.equals(ShowSql.FALSE) == true and that bothers him.
So he changed the implementation of Option / UniqueOption to behave like I
previously explained for generic options but to properly return
ShowSql.equals(ShowSql.FALSE) == false. To do so, he removed
getOptionIdentity() and manually ask (Unique)Option implementors to implement
equals. In his example equals for ShowSql would be based on the value.
So we are at an impasse.
I hate his approach as the equals behavior is inconsistent between generic
options and unique options. It's very confusing for an Option implementor to
figure out what equals should do. And ice on the cake, the implementor has to
implement equals / hashCode instead of delegating that to the superclass: more
code, more opportunities to screw it up.
To me the fact that ShowSql.equals(ShowSql.FALSE) == true is indeed inelegant
but AFAIAC is a degenerate case and shifts the identity from Option to Option +
Option Value which is useless.
Gunnar cannot figure out what I am even saying and to him equals() should
behave naturally period and the hell with consistency.
I see four ways out:
1. we stay how it is today with the weird equals behavior in case of constants
and keep the concept that an Option is not identified by its value.
2. we move to Gunnar's position that an Option is uniquely identified by its
family + value for unique options and keep generic options identity by family +
key (and not value)
3. we move to Gunnar's position but all the way: an Option is uniquely
identified by its family + value both for generic and unique options
4. we fall back to differentiate in the type system option family, option key,
and option value.
So what do you guys all think of this problem?
Emmanuel
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
