[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ozone IDs through XML import/export
On Sun, 11 Mar 2001, Reason wrote:
> >> Am I correct in assuming the presence of object IDs in the Ozone export
> XML
> >> means that internal database IDs [i.e.
> >> ozoneobject.container().id().getValue()] will remain invarient through a
> >> cycle of exporting the entire database as XML and then importing it to a
> >> fresh and empty database?
> >
> >Yes, the remain invariant. The object ID _is_ the identity of an object.
>
> Not that it matters for the purposes of my project, but I assume that this
> means that you can't import safely to a database with objects in it already?
> Is there any mechanism in place to handle ID collisions?
No. Merging two versions of the same database doesn't make sense anyway.
Providing such a mechanism would mislead people to use the backup feature for
unintended things. Merging tables of a RDBMS works and makes sense because the
algebra, the operations and their semantics is well defined. In an OO system
only the business logic of the application knows how the objects works together
and what are the (valid) relations.
>
> >> I'm in the process of hacking together a restricted object description
> model
> >> for some later development that requires all objects to have a unique ID
> and
> >> reference one another via this ID rather than containment or Java
> >> references. (Don't ask: it makes sense in context :). Using the internal
> >> Ozone methodology of ID assignment is the easiest method of unique ID
> >> assignment by far, but invarience across imports/exports becomes
> >> important...
> >
> >The only problem I see is that ozone object ID are not meant to be
> explicitly
> >used by client code. There is no 'official' API to access them. So, there
> is a
> >very very small chance that this API will change in future versions.
>
> Yes; for large ongoing databases with a heavy turnover of objects, one would
> imagine a few alterations will have to be made to the existing code -- as I
> understand it -- just to close off potential problems with long-term use.
>
> Hmm. Being able to assign and access unique IDs for persistant objects is
> very useful for several classes of application -- mine included. Problems of
> synchronization start to arise when you have a project requiring unique IDs
> and multiple client access -- any ID assignment code must be on the server
> side. It seems silly to replicate it when there's one there already, and
> it's a useful function of a database. Perhaps making it more accessible --
> or at least keeping it at the current level of accessibility -- and
> providing a quick import/export update hack when the API changes?
_If_ this internal ozone API ever changes, then we will surely provide a way to
migrate the data. The real problem is your code. If you are using internal API,
then this code will simply not compile.
Anyway, I don't expect ObjectID and related things to change that much in the
future. I just wanted to note this point.
>
> (Yes, I realize who will probably end up doing that :)
>
> Do you think that shifting the ID to String type impact Ozone performance
> noticably? Gives you more room for IDs and wiggling out of the ID already
> assigned problem for the aformentioned large database.
Using Strings instead of an integer type would surely impact performance. The
kernel has to search the target object of an ObjectID for each and every method
call! This definitely is one of the hotspots. I tried to optimze the method
invoke code chain as good as possible. Performing a String compare instead of an
integer compare on _each_ method call would definitely slow down the entire
system.
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com