[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone object identity...
> 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.
---
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:
public String identity();
public boolean isSame(Object obj);
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. :)
David Li
DigitalSesame