Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Users List" <torque-user@db.apache.org>
Message-ID: <21115DCA7CC1D51189F100E0181E406501142A43@bavc001a.bav.siemens.ro>
From: Dovlecel Alexandru Ovidiu <alexandru.dovlecel@siemens.com>
To: "'Apache Torque Users List'" <torque-user@db.apache.org>
Subject: RE: hashCode/equals contract broken in BaseObject
Date: Tue, 4 May 2004 17:39:04 +0300 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

When you are right you are right. 

Thanks for reminding me the Hash logic. Forgot about the collisions :(((
Silly me. Thanks again. (btw, cormen is quite a big book that lies in my
library, collecting the dust) :)))) 

Then keep up the fight for the changes,
Alex 

-----Original Message-----
From: Shevek [mailto:shevek@anarres.org]
Sent: Tuesday, May 04, 2004 4:37 PM
To: Apache Torque Users List
Subject: RE: hashCode/equals contract broken in BaseObject


On Tue, 4 May 2004, Dovlecel Alexandru Ovidiu wrote:

> I think the approach that you provide will not work, because the XOR
> operation will produce overlapping hashkeys. For example the following two
> couples will provide the same key, even though they are different objects:
> 
> (class.hashCode in binary, pk.hashCode in binary) --> object.hashCode
> 
> (1110, 0001)  --> 1111
> (1010, 0101)  --> 1111

That doesn't matter, as long as equals() discriminates correctly between 
the objects. Collisions are a natural feature of any hash algorithm, 
by the very fact that a hash function is lossy. Equals must look like:

(getClass() == ob.getClass()) && (key == ob.getKey())

Right now, all the hashcodes are likely to be equal anyway since they all
just use the primary keys, so in fact the situation is currently worse 
than you suggest.

> So an object of type identified by 1110 (14) that has the pk.hashCOde
equal
> to 1
> WILL BE EQUAL 
> with an object of type identified by 1010 (10) that has the pk.hashcode
> equal to 5

No. They just have the same hashcode. They are not equal. That is why 
there are separate hashCode() and equals() methods in Java. The equals 
method must ONLY return true if the objects really are equal. hashCode() 
can return whatever it likes, but performance will improve if collisions 
are reduced. It's fairly common to stress test hash implementations by 
making hashCode() always return zero. However, equals() must always work.

To be honest, as long as BaseObject::equals() gets fixed, hashCode() can 
stay as it is (but performance will still suck).

> If I am wrong (I am not too good with the binary operations and the binary
> format) pls correct me... 

I suggest Cormen, Rivest, et al. Algorithms, 2nd ed for a basic
illustrative description of hashing. Knuth for the more complete
description.

S.

> Enjoy,
> Alex 
> 
> 
> 
> 
> -----Original Message-----
> From: Shevek [mailto:shevek@anarres.org]
> Sent: Tuesday, May 04, 2004 4:22 PM
> To: Apache Torque Users List
> Subject: RE: hashCode/equals contract broken in BaseObject
> 
> 
> On Tue, 4 May 2004, Dovlecel Alexandru Ovidiu wrote:
> 
> > You can use torque objects as hash keys with one condition: 
> > 
> > all the keys in the hashtable must be instances of the same torque
class.
> > Then you will not have any inconsistency. 
> 
> I know this. However, this is in violation of the equals() contract and
> causes much breakage. equals() should return true if and only if the
> objects are equal. I have a requirement to mix class types. I have
> suggested a fix for this: use
> 
> 	getClass().hashCode() ^ key.hashCode()
> 
> instead of
> 
> 	key.hashCode()
> 
> Then the whole world will work as intended again.
> 
> S.
> 
> > -----Original Message-----
> > From: Shevek [mailto:shevek@anarres.org]
> > Sent: Tuesday, May 04, 2004 4:07 PM
> > To: Apache Torque Users List
> > Subject: hashCode/equals contract broken in BaseObject
> > 
> > 
> > hashCode and equals in BaseObject rely only on the primary key. This
> > breaks horribly (violates the general contract of hashCode()/equals())
if 
> > you compare two objects of different classes.
> > 
> > It MUST compare ob.getClass() as well as ob.getPrimaryKey() and include
> > ob.getClass().hashCode() in its hashCode() [by xor?] [or something
> > equivalent].
> > 
> > No doubt the reason for this violation is noted in the FAQ, but it seems
> > worth noting as a serious bug since it means I can't use Torque objects
as
> 
> > hash keys.
> > 
> > S.
> > 
> > 
> 
> 

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org