[hibernate-dev] [OGM] Option identity

[Gunnar Morling]

2013/10/21 Emmanuel Bernard <emmanuel at hibernate.org>

> 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.
>

Actually the issue I came across is ShowSql.TRUE.equals(ShowSql.FALSE); Or
in more subtle representations:

    //would be true also if actually FALSE was contained
    assertThat( optionsContainer ).containsOnly( ShowSql.TRUE );

    ShowSql.valueOf(true).equals(ShowSql.valueOf(false));

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.
>

That's not quite right, maybe this already is the source of our
disagreement. I only removed the final implementation of
UniqueOption#getOptionIdentifier() (which was based on the specific
sub-type of UniqueOption). Option#getOptionIdentifier() is still in place.

So an option implementor has to implement getOptionIdentifier() in both
cases, for unique and non-unique options. He doesn't have to implement
equals() himself (which is implemented in the Option super-class and takes
into account the specific option type and the result of
getOptionIdentifier()).

>
> 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.
>

As outlined above an option implementor only needs to provide
getOptionIdentifier(). The only difference to the situation before is that
he needs to provide that method for unique option types now, too.

Does this alleviate your concerns about the proposed change?


> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>