Well, I was actually wanting a "get" in the name to work with OGNL, so
it wouldn't redefine hashCode().
The System.identityHashCode() would probably work fine, but isn't
callable by OGNL. Come to think of it, just being able to call
hashCode() from OGNL would be useful, too (and equivialent to
System.identityHashCode()).
So, would it make more sense to add a getHashCode() (which is just an
OGNL friendly cover method) to CDO or to customize my templates? :-)
Thanks,
/dev/mrg
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Wednesday, June 21, 2006 12:46 PM
To: cayenne-de..ncubator.apache.org
Subject: Re: Add getHashCode() to CayenneDataObject?
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:kmenar..ervprise.com]
> Sent: Wednesday, June 21, 2006 12:11 PM
> To: cayenne-de..ncubator.apache.org
> Subject: Re: Add getHashCode() to CayenneDataObject?
>
>
> On Wed, 21 Jun 2006 11:58:07 -0400, Gentry, Michael (Contractor)
> <michael_gentr..anniemae.com> 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
>
>
This archive was generated by hypermail 2.0.0 : Wed Jun 21 2006 - 12:54:25 EDT