[hibernate-dev] [OGM] Option identity
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
Re: [hibernate-dev] [OGM] Option identity
2013/10/21 Emmanuel Bernard
> 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] Use cases for many-to-many collection of proxies?
Are there real-world use cases where an initialized many-to-many collection should contain elements that are uninitialized proxies (HibernateProxy), rather than entity instances? Currently, it is possible to configure this behavior using either: We are considering removing this capability if there are no real-world use cases. Fetch profiles do not provide this level of granularity. The fetch style for the collection itself, but not its elements, can be configured using a fetch profile. As far as I know, JPA does not provide this level of granularity either. Please let us know if you are using this functionality. Thanks, Gail ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Use cases for many-to-many collection of proxies?
Hi Gail, does this impact as well the "extra-lazy" collections? I definitely had great use cases for them in the past. On 21 October 2013 19:22, Gail Badner wrote: > Are there real-world use cases where an initialized many-to-many collection > should contain elements that are uninitialized proxies (HibernateProxy), > rather than entity instances? > > Currently, it is possible to configure this behavior using either: > > > > > We are considering removing this capability if there are no real-world use > cases. > > Fetch profiles do not provide this level of granularity. The fetch style for > the collection itself, but not its elements, can be configured using a fetch > profile. > > As far as I know, JPA does not provide this level of granularity either. > > Please let us know if you are using this functionality. > > Thanks, > Gail > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
