I think redefining CayenneDataObject.hashCode() is a bad idea for the
reasons that Kevin has mentioned, and also because of uniquing (two
objects with the same OID can sit in different contexts, so logically
they are not the same ... they can still have the same hashCode, but
this can be confusing).
Any thoughts on this? Or is there another way to get a unique
value for
an object that doesn't expose the entity/keys? If only Java let me
get
the pointer (I miss &).
It gives you something close to the pointer address -
System.identityHashCode(). Of course it won't be preserved on server
restarts and across the cluster (so do not save it in serialized
sessions)
Andrus
On Jun 21, 2006, at 8:30 PM, Gentry, Michael ((Contractor)) wrote:
Ah, but will two DOs of the same class with null OIDs have the same
hash
code? If so, that would be bad, too.
My basic desire is to get a unique value (an int is fine, or a short
string, etc) for every DO that does not include entity/key information
and the value must be reproducible. If I could just take the
address of
the DO ... Hahaha. So, I'm open to thoughts on this ...
Of course, you could argue I'm just being a security nazi, too. You
should see people's (seasoned web developers) eyes bugger out when I
show them how I can edit their "secure" HTML in OmniWeb, change all
the
hidden form values, and post it back to their application. They
thought
that was impossible. (Of course, you can do the same with curl, too,
but it is more difficult.) Never trust the client-side data.
Thanks,
/dev/mrg
-----Original Message-----
From: Kevin Menard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 12:11 PM
To: [email protected]
Subject: Re: Add getHashCode() to CayenneDataObject?
On Wed, 21 Jun 2006 11:58:07 -0400, Gentry, Michael (Contractor)
<[EMAIL PROTECTED]> wrote:
Would it make sense to add:
public int getHashCode()
{
return getObjectId().hashCode();
}
Any thoughts on this? Or is there another way to get a unique value
for
an object that doesn't expose the entity/keys? If only Java let me
get
the pointer (I miss &).
My only concern is expanding the code to work with DOs that aren't yet
registered with a DC. In that case, the OID is null, so the above
code
breaks. In order to not break the equals() contract though (I'm
assuming
you want getHashCode() to work similarly to hashCode()), you just have
to
be careful how you deal with null values. In particular, two DOs
created
from different classes, both with null OIDs probably shouldn't
have the
same hash code.
--
Kevin
