[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ozone object identity...



On Tue, 01 May 2001, David Li wrote:
> > ok. What you are saying is: hashCode() + equals() does not 
> > make up the identity of an object. 
> >
> > I agree. But this wasn't the problem. The problem was that 
> >
> > 1) we wanted to use a proxy as a key in a hashtable and 
> > 2) we needed something that we could store and find the
> >    corresponding object in the db later on.
> >
> > Olas suggestion to return an object that properly implements
> > hashCode() + equals serves both 1) and 2) well.
> 
> I think we agree on that an object's hashCode() + equals() doesn't
> translate well into its identity. 
> 
> I totally agree with your points here. We are looking for something with
> the following properties.
> 
> 1) to be used as a key in the hashtable or Java Collection
> 2) something to be stored locally and use to retrive the object
>    later.
> 
> Olas's suggestion fits well for the above. Let me futher putting this
> into a more formal context.
> 
> Let ozOne and ozTwo be two Ozone object. We are looking for something we
> can retrive from the objects to fulfill the above properties. For the
> sake of the argument, let's call that property object identity and can
> be retrive by calling getIdentity() method on the proxy objects. 
> 
> So, we will have the following statement will hold:
> 
> ozOne.getIdentity().hashCode() 
>   == ozTwo.getIdentity().hashCode()
> 
> AND
> 
> ozOne.getIdentity().equals(ozTwo.getIdentity())
> 
> If and Only If
> 
> ozOne is identical to ozTwo
> 
> I think the String representation suggested in my previous mail satisfy
> the two properties we are looking for.
> 
> > Except that my idea of naming the method that return this
> > object 'identity()' does not really correspond to the idea
> > of this method. This breaks my own ideas since, as I stated
> > from the beginning, I do not want to give the programmer an
> > ID or identity or something like that.
> > 
> 
> I can understand the requirement of not introduction any additional API
> calls for the programmers. I am all for that. If we need to introduce
> any additional API, we should keep it at the minimum and they should be
> "rarely" needed in most Ozone programming.
> 
> However, we have to face the fact that Java's semantics are designed for
> transient objects and doesn't fit well with the idea of persistent
> objects. We miss the ability to telll us whether two objects are
> "identical" with the persistent objects.
> 
> We are facing a design problem here with two competing goals.
> 
> 1. We don't want additional API for programmer
> 2. Programmers need something that can tell them 
>    whether two objects are identical or not
> 
> > This is true and perfectly intended. I just substituted '==' by isSame() for
> > persistent objects. The contract of hashCode() and equals() are the same for
> > transient and persistent object - that was the idea! (at the same time
> > time this lead to the mentioned problems when using proxies as (efficient) keys
> > in hashtables)
> > 
> 
> I agree that the contract of equals() and hashCode() should be uphold
> for both transient and persistent objects. However, it's also the true
> that persistent object can't impose any additional requirement and
> constraint on the two methods.
> 
> The root of the probelm is that Ozone has impose additional requirement
> on those two methods in term of trying to make the following true.
> 
> objOne.hashCode() == objTwo.hashCode() 
> 
> AND
> 
> objOne.equals(objTwo)
> 
> IF AND ONLY IF
> 
> objOne is identical objTwo
> 
> This statement isn't true with the contract of hashCode() and equals()
> in the transient object.
> 
> > > and an identity is the most important value of an object in
> > > a OO world.
> > 
> > True but again, IMO the programmer does not need a way to
> > directly access this identity of a persistent object.
> 
> Well... The two condition I encounter here as a programmer calls for
> acceessing the identity of a persistent object. 
> 
> 1. To build attribute of a persistnet object, I need something as a
> value for the indexing. 
> 
> 2. To build a client side cached implementation (for small VM), I need
> to be able to save something on the client side and use that thing to
> retrive object later on.
> 
> > > The format of the URL will be roughly look like the following:
> > >
> > > ozonedb:remote://ozone.d11e.com:3333/com.d11e.MyObject/1.0/1234/5678
> > 
> > Hmmm.... I don't like this. (read on!)
> > 
> > People will start interpreting this String and using it and depending their
> > code on the format of this string.
> > 
> 
> Well... We just have to put a warning on such usage. A good warning are:
> 
> "The format of this string is subjected to change in the future version
> of Ozone. Do not depending on the format in your program." 
> 
> We may be able to use Aspect to detect such usage. (www.aspectj.org)
> Just an idea here.
> 
> > I still don't see the need to give the programmer something that represents the
> > identity of an object. Something that properly implements hashCode() and
> > equals() is enough for all use cases that I can think of.
> > 
> > Anyway, maybe we decide to return your String, David but we should not
> > document the format of the string and voila!... we are there.
> > 
> 
> String fits the bill. The hashCode and equals of String will satisfy the
> two properties we are looking for. We will not document the format for
> general usage but probably should be documented to the Ozone "kernel"
> developers.
> 
> For the small VM implementation, I am thinking of saving the identity in
> seperated part:
> 
> 1. database will keep the server part.
> 2. the classname and class version will be kept in the class object.
> 3. version and id will be kept in the object.
> 
> A call to getIdentity() of the object will return the combination of the
> three.
> 
> > > I'd propose the following addition to an OzoneRemote interface:
> > >
> > > public interface OzoneRemote {
> > >     public String getObjectIdentity();
> > 
> > We should consider to not name this getIdentity() but getKey() or something.
> > (yes I know, I proposed identiy() in the first place)
> > 
> > >     public String getObjectIdentityHash();
> > >     public boolean isSame(Object obj);
> > > }
> > >
> 
> getKey is kind of confusion but it may work. 
> 
> Let me try to summarize the discussion so far. 
> 
> 1. We need to be able to get "something" from an Ozone object that
> satisfy the following properties:
> 
> 1) to be used as a key in the hashtable or Java Collection
> 2) something to be stored locally and use to retrive the object
>    later from the database.
> 
> 2. From the discussion, the object's identity will satisfy such
> properties. So, for the sake of discussion, let's use object identity
> for this thing.
> 
> 3. We don't want to expose the internal of this "identity" to the
> programmer such its format.
> 
> 4. the programmer should be able to use hashCode() and equals() on the
> identity of objects to express the identical relationship between
> objects.
Agreed.

We need a way to determine if to object are identical. Period. Today this can
be done via OzoneProxy.isSame(). I agree that this is not a good solution since
we need something to use as key in hastables and something that we can store
and use later to get an proxy for the corresponding object.

All this has to do with the identity of the object. And it is best handled via
an Java object that represents the identity via proper implementation of
hashCode(), equals() (and, if possible) the == operator. I agree on this too,
now ;)

The 'implementation' of the identity object could be String because then we
support the '==' operator, right? Okay. (I will comment on the format of this
string later)

> 
> ---
> 
> I need to hack up a quick demo for Waba and Ozone this week. I will
> modify my local copy of Ozone to experiment with the idea of of using
> String for the identity type and add only two methods to OzoneRemote:

OzoneRemote was meant as a tagging interface only. Adding methods to it means
that we have them on _both sides, database and proxy. So OzoneCOmpatible and
OzoneObject would have to provide implementations for it.

The straight forward way is to add it to OzoneProxy but then we need an
additional cast...

> 
> public String identity();
we could have Object as return type without breaking anything, right. If this
is true, then I would like to return Object.

> public boolean isSame(Object obj);

Hm....??? we did all this to get rid of my isSame() and now it is there again?
We don't need this, right? o1.identity() == o2.identity() (or
o1.identity().equals( o2.identity()) should be okay. (?)

> 
> Using String for the identity has the following advantages:
> 
> 1. hashCode() and equals() of String already satisfy the properties we
> are looking for.
> 
> 2. If we called intern on the string before we return it from the
> identity, we get additional semanics on:
> 
> ozOne.identity() == ozTwo.identity() does express the identical
> relationship of two Ozone objects. :)
this is really cool :)


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com