[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Ozone object identity...
Matt Smith m.smith@secureinteractive.com
Technical Lead www.secureinteractive.com
> -----Original Message-----
> From: Eric Richardson [mailto:eric@milagrosoft.com]
> Sent: Friday, 4 May 2001 10:03 AM
> To: ozone-dev@ozone-db.org
> Subject: Re: Ozone object identity...
>
>
> Matt Smith wrote:
> >
> > I've been following this thread on and off, so forgive me
> if i'm out of
> > line...
> >
> > Wouldn't using a hardware id tie you into that one machine?
> What if the
> > machine was upgraded? If you used a machine id such as its
> host name, then
> > it is transparent what is behind it. Could even be an
> Ozone cluster. So
> > long as it knows about the right objects, does it matter?
> Do these issues
> > exist in Versant? How do they avoid them/get around them?
> >
> > I'm sure there is a good reason for everything, but I am
> just curious (or
> > ignorant?) as to why you need such a low level identifier.
>
> No these are tough problems and so far nobody has really commented on
> the issues of import/export and replication and other issues.
>
> Are copies of objects the same object or a new object?
Does it matter? If I put my Car object into Ozone, as long as I can get a
Car object with the same state back, that should be ok, right?
There has been a bit of talk about the methods an object should have to work
with the identification system. What I understand from that talk is this:
- equals() returns true if the objects share the same state (eg. two
Strings, both containing "Hello World")
- isSame() returns true if the objects are actually the same object (ie
obj1 == obj2)
I don't understand the need for isSame(). If two objects are the same type,
and share the same state, then does it matter that they are not actually the
same object?
>
> If I export an XML representation, does the OID come along
> and then will
> the OID comflict in your ozone server if you import the file?
I would think that the OID would not stay. If you imported the object, it
would get a new id. The id would be for each server only, and so guarenteed
to be unique within that database. To make it globally unique, you would
qualify it with other fields such as ozone instance id and the servers
domain name.
I guess we can make a comparison to a DBMS such as Oracle. Ozone and Oracle
both store information - Oracle stores it as primitives, Ozone as objects -
but it is all data (that is the reason for storing it in the first place,
right?). When you set up an Oracle server, it has a domain/host name. You
then create an instance for a database, which is given a service name. Then
each row of data within Oracle is given a rowid. If you work only inside
Oracle, say with stored procedures, then you can use rowids if you like.
But each time you step out a level, you have to add another level to the
name of the data in order to get there.
This same logic should be applicable in Ozone. Just give all objects an id
that is unique within that server (Ozone already has a method for uniquely
identifying objects, doesn't it?). You can then qualify your reference to
that object with a service name and a domain name if you need to. I don't
really see the need for a singe globally unique number. If all you need is
a way to identify each object in the database, then you already have it!
(except maybe not the service name?).
This would fit in with RDF - the triple would be domain name, service name,
object id. Is this a valid solution, or have I just grossly oversimplified
the problem?
>
> I'm by no means an expect on random number generator but you have to
> have a heck of a good method so my VM and your VM never
> produce the same
> number. Here is how I understood the logic behind the composite three
> number thing. If machines are unique which they are since
> they are true
> objects then even if the object part is a sequencial thing 1,2,3 ...
> then the combined OID (machine part + object part) is unique. But you
> can also have more than one instance of Ozone running on the
> same box so
> you need to take that into consideration as well which is why
> there is a
> objectbase part as the second component.
>
> The true GUID approach must take a seed and random generator
> in which n
> streams never produce the same number even with numbers of
> object larger
> than I can perceive.
So what you are saying here is that the ethernet id would be used as the
seed for the GUID?
>
> I certainly don't know if this is needed but since a worked
> with Versant
> for a couple of years I thought it might be applicable.
>
> Eric
>
>
> > > Eric Richardson wrote:
> > >
> > >
> > > Michael Keuchen wrote:
> > > >
> > > >
> > > > Remember that the identity can not be GEU in all cases, e.g.
> > > > when using a local database or a RemoteDatabase in an intranet.
> > > > The identity can store as many informations as possible
> about the
> > > > object location, but global uniqueness is not ensured.
> > >
> > > Microsoft has an algorithm for DCOM I believe provides a GUID
> > > (Globally
> > > unique ID). Versant and their three part ID based on machine id +
> > > objectbase id + object id claimed to be unique.
> > > I think the three part scheme make alot of sense although
> I don't know
> > > how to get the ethernet id in Java for the first part but
> we know that
> > > ethernet id is unique otherwise TCP/IP wouldn't work. I
> discussed this
> > > in another part oif this thread.
> > >
> > > Eric
> > >
>