Public: Concord Software Projects : OTrunk ID System
This page last changed on Jul 03, 2007 by scytacki.
OTrunk uses ids to look up and store references to objects. The root class of this system is an empty interface called OTID. This interface is implemented by:
A user of the OTrunk system shouldn't have to worry about these different types of IDs, but there are a few places where they show up.
In the current system most people have used local_ids in their otml files. Most of these ids are handled when the document is loaded. They are replaced with: (otml UUID)!/(local_id). So for example a object with a local_id like this:
While get converted and when it is saved again it will look like this:
The UUID was taken from the otrunk element of the initial document.
local_ids are referenced again using a syntax:
OTUUID - provides a OTID implementation that uses a UUID for the id of the object. Currently when a new OTObject instance is created in the Java code a new OTUUID is created for that object. OTUUID's are strongly encouraged for each otml file which is created, this id is specified in the otrunk element at the root of the document. Something like this:
OTRelativeID - provides a way to reference an id relative to another id. This class has a rootId and a relativeId. It is typically used to store the local_id style ids above. So the local_id is relative to the root id of the otml file. When this id is written out the "!" character is placed between the root and relative ids.
OTPathID - this id is used by the current xml representation to store an id based on the path to the object in the document. So if you create an OTObject in a otml file which doesn't have a local or global id then a path id is used. The path id is based on the location of this OTObject in the otml file. An example of a PathID is:
The path is divided by the "/" characters. This id illustrates several parts of the path ids. The first element is an object with an id attribute set to a UUID. The next element says this points to the first service in the services feature/property of the first element. The next points to the second mode in the modes feature/property of the service. The next points to the map entry which has the key:
A new OTDatabase might work best with a different ID design.
The problem with this is that it means the OTIDFactory needs to know about this new ID system. That method has been hidden behind 2 layers of abstraction, so it should be possible to work with those layers to support multiple ID system. However the OTIDFactory.createOTID method is still called in 11 places, however all of those places are internal to the OTrunk system so they are under our control.
The first abstracted way of getting an id is to use the OTrunk method getOTID(String id).
The second abstraction is the OTObjectService method getOTID(String id). This is used in 4 places:
So the issue that needs to be dealt with is how the OT system can identify which data storage library should convert an id string to an actually OTID. It might work to say that an OTObjectService has to be associated with a particular data storage library. The OTObjectService already had 2 databases the creationDb and the mainDb. Each of these could be a different type of database. It seems the safest approach would be to require that the call of the method needs to also pass in the OTObject that is making this string based id reference. Then the database of that object can be looked up and it can be used to create the id. Even this could still be a problem in the case of overlayed object, like the user object. The overlaying object might be in one type of the database and the underlying object in another type. In this case simplying having the OTObject is not enough. The system would need to know the property of the object, to see which database that property comes from for this particular object.
Another alternative is to remove ids entirely from being used as strings within properties. There are 2 cases that need to be dealt with here:
If we do all of these changes then it will simplify the copying code, and database implementations. The OTID string issue will go away.
The tough case here is when copying from one data store to another. Currently this type of copying happens below the level of the OTObjectService.
|Document generated by Confluence on Jan 27, 2014 16:52