[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ozone IDs through XML import/export
>> 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?
>> 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?
(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.
Reason
CTO, VIPMobile