Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The Object ID (OID) is the universal internal identifier for all persistent objects.

Properties

  • System-wide unique. The OID must be unique within the IDM system. No two objects may have the same OID. Not even two objects of different types. This property allows to use OID as a system-wide identifier for object references, as a primary key in tables, etc.
  • Probably globally-unique. The probability that two OIDs in two different IDM systems are the same should be extremely low. The OID generation process should include some randomness to get this property. This provides easier migration of objects between systems (e.g. from test to production), copy&paste of objects, the ability to maintain references while copy&pasting, etc.
  • Human unreadable (ugly, random-looking form). This property will discourage the practice of creating fixed, easy to remember OIDs. Fixed OIDs are hardcoded constants and should be avoided.
  • Relatively long. This is an effect of other properties rather than a desired feature. However prepare the code, tools and processes that OIDs will be tens of characters long.
  • Not reassignable. OID assigned to one object should not be assigned to any other object. This is not really a strict requirement, adding sufficient amount of randomness to OID generation should be just fine. If the OIDs cannot be reassigned we can easily detect broken links. If we ever reassign on OID, the link (reference) that should break will appear to be valid. Broken link is definitely a lesser evil in this case.
  • Internal to the IDM system. OIDs should not be shared with any other system outside IDM. E.g. OIDs should be used as psoIDs in SPML. We want to keep OIDs internal to be able to regenerate them e.g. in case of upgrades to the version with different OID format.

TIP: UUID seems to be a good candidate for OID

OID Generation

OIDs shoud be generated at a single place in the system. It should be the lowest component that works with the database, so it can efficiently check OID uniqueness.

The operations of many interfaces will accept already generated OIDs when creating objects. However, these operations may fail if provided OID is in a unusable format. The feature to accept existing OID is there especially to allow object migration and copy&paste. But we support export/import of OIDs only for systems that use the same (or very close) versions of the software.

  • No labels