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

Re: Ozone object identity...



On Fri, 27 Apr 2001, David Li wrote:
> Falko Braeutigam wrote:
> > 
> > On Fri, 27 Apr 2001, David Li wrote:
> > > Here is the problem I have at hand.
> > >
> > > In RDF, Model is a "set" of Statements which are "triples" of (Resource,
> > > Resource, Resource|literal).
> > >
> > > In the design, Model, Statement and Resource are implemented as
> > > persistent object in the Ozone DB. Model and Resource are named using
> > > their URL. The user of the RDF DB will query the model using a
> > > find(resource, resource, resource|literal) pattern in which null means
> > > all match wildcard.
> > >
> > > The implementation use two indexes on the names of the first and second
> > > resource of the triple as the key and statement object as the value.
> > >
> > > However, statement is not named for two reason. First, it doesn't make
> > > much sense to name statement as their are not often refered by name
> > > because of the search/query model above. Second, naming the statement in
> > > a unique fashion by the model will complicate the implementation. Also,
> > > from time to time, some statement can be named using URL and this will
> > > conflict with the naming in the model itself.
> > >
> > > So, in here, I'd like to use the object id of the statement object as
> > > the index value and leave the naming part for the programmer.
> > >
> > > I agree to present the Ozone to client side programmer as totally
> > > transparent object persistent system.
> > >
> > > However, for the server side logic programmer, they should be able to
> > > access the object identity as this will be great help for the server
> > > side system. I believe the same issues will raise from the query kernel
> > > as well.
> > 
> > I'm not sure if I got this right, anyway...
> > 
> > The proxy _is_ the identity. In fact, the hashCode() method of OzoneProxy
> > (if not overwritten by the target object) returns the lower 32bit of the object
> > ID. So, proxies itself can be used as keys in hashtables, indexes in
> > tables or something like this.
> > 
> > Falko
> 
> I see what you mean by Proxy object is the identity. However, we do have
> to override the hasCode to store statement in a standard Set object. But
> knowing such is a good starting point.
> 
> I will try to look arround to see if adding a getObjectIdentity() and
> getObjectByIdentity() is a good idea Ozone. I understand the need to
> keep the API clean for the Ozone developer. However, we need a way to
> get object identity for the persistent one. 
> 
> After all, each object should have an identity. For transient Java
> object, the object id is the "pointer" to it. We need to provide
> equivlance to that in Ozone object.
> 
> Using default equals and hashCode may not be such a good idea since
> there may be need in application to override those two methods.

On the other hand it's a very good idea since it allows to handle the
persistent object identity of ozone the same way as the identity of transient
objects. For transient objects you can easily determine if two object are the
same but you can _not_ access the pointer/id/reference/whatever-it-is-in-Java
directly. The proxies of ozone act the same way.

Anyway, sometimes you have to change the behaviour of hashCode/equals, which
then breaks this model. What about a identityHashCode() method?

Also, David, what do you want to return from a getObjectIdentity() method? The
internal object ID? This would make client code depend on the internal
implementation! (the current 64bit number is one solution maybe we have to
change this for some reasons in the future)

So, I would like to avoid to have a method that appears to return the object
ID of an object back to the client. This, IMO, leads to wrong designs. We
don't need this as Java doen't need pointers. The identityHashCode() in fact
does nothing else but people would not expect a getObjectByHash() method
somewhere in the ozone API because such a method does also not exist in the
Java model in general.

getObjectIdentity() / getObjectByIdentity() are wrong IMO and would break the
design of ozone.


BTW: I don't know whats wrong with the mail lists. Lars will check this as
soon as possible.


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