What's about string ant integer comparison?
Will the AST parser allow it or fail with the same error?
The following SQL statement:
SELECT 'Comparison OK' WHERE cast(1234 as integer) = cast('1234' as
varchar);
Returns 'Comparison OK' on MS SQL Server, but fail on PostgreSQL (and
certainly other RDBMS) with following error:
ERROR: operator does not exist: integer = character varying
This already cause me some troubles when trying to port applications to
PostgreSQL, or to pass NHibernate's tests against PostgreSQL.
I will be happy if the new parser will throw an exception in that case,
as this will force developers to write more portable NH queries.
Regards,
David
Steve a écrit :
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
