True enough, although every override I've seen of .Equals would barf
if the types weren't comparable. As you say, the default
implementation looks for reference equality, so it would never return
true for two objects of a different type.
The classic parser certainly passed this test, just doing the
comparison with the Ids. Hb fails this test with it's AST parser,
with the same error, so they took the choice that the explicit .Id
would be required. Here's the Hb output:
10:51:36,474 INFO UnitTestCase:80 - Completed test
[org.hibernate.test.legacy.ABCProxyTest#testOneToOne]
org.hibernate.TypeMismatchException: left and right hand sides of a
binary logic operator were incompatibile
[org.hibernate.test.legacy.A : org.hibernate.test.legacy.E]
at
org.hibernate.hql.ast.tree.BinaryLogicOperatorNode.mutateRowValueConstructorSyntaxesIfNecessary
(BinaryLogicOperatorNode.java:85)
On Apr 15, 10:36 am, Sidar Ok <[email protected]> wrote:
> - In .Net, you can't compare two
> types that are different.
>
> This is not quite true. You can compare 2 objects, and every object inherits
> from an object. If you want to match .NET behavior, I think it should work
> because in objects, there is a default Equals implementation which compares
> the handles and in HQL default is id, where default means that if it is not
> overriden it should be the behavior.
>
> How is it done in other parts of HQL, is there any other situation that's
> already decided in somewhere else in HQL ?
>
>
>
>
>
> On Wed, Apr 15, 2009 at 10:07 AM, Steve <[email protected]> wrote:
>
> > My call is that it shouldn't work. In .Net, you can't compare two
> > types that are different. Just because the Id's happen to match
> > doesn't imply equality in any way, IMO. Being forced to add the .Id
> > (as in e.Reverse.id = a.Forward.id) makes the developer's intentions
> > clear.
>
> > Note that if the types match, then the .Id isn't necessary. So
> > "e.Reverse = e.Reverse" is absolutely fine (poor example, since it's a
> > tautology, but I'm sure you get the point!).
>
> > Whether we're happy to take a breaking change is another issue. My
> > feeling is that the new parser should *not* be the default, that way
> > any breaking changes (either intentional or accidental through unknown
> > bugs) won't impact the community. If anyone wants LINQ support, or
> > bulk updates, or any other feature that requires the new parser, then
> > they should be explicit in their configuration and make sure that they
> > run a full regression test of their system. That way, we don't have
> > to be quite so concerned about making the two parsers match
> > exactly. I think that there are good advantages to staying roughly in
> > sync with Hb, and these breaking changes are ones that they seem to
> > have been happy to take.
>
> > On Apr 15, 8:53 am, Ayende Rahien <[email protected]> wrote:
> > > So, should it work or shouldn't it work?
>
> > > On Wed, Apr 15, 2009 at 9:33 AM, Fabio Maulo <[email protected]>
> > wrote:
> > > > 2009/4/15 Ayende Rahien <[email protected]>
>
> > > >> I would say that this should be broken then.
> > > >> What I would expect it to do is compare the ids, but that is okay,
> > since
> > > >> we can just user e.Reverse.id = a.Forward.id
>
> > > > but the default, in case of relations, is the id
>
> > > > --
> > > > Fabio Maulo
>
> --
> Sidar Ok
>
> http://www.sidarok.comhttp://www.twitter.com/sidarok
