-
Notifications
You must be signed in to change notification settings - Fork 2
Poid
As seen in Wikipedia
In database design, a Persistent Object Identifier (POID) is a unique identifier of a record on a table, used as the primary key. Important characteristics of a POID are that it does not carry business information and are not generally exported or otherwise made visible to data users; as such a POID has many of the characteristics of a surrogate key. The only purpose of the POID is to act as the primary key on the table where it is defined and to be referenced as the foreign key by other tables. Because POIDs, like surrogate keys, do not carry business information, they are immune to changes in the form or meaning of business data.
There are entities in dust that represent a "thing" in the real world. This is indicated in the type definition of their primary aspect (what this entity really is). For a "world" lifecycle type, that type instance must also contain an InstanceProvider aspect as well, which is responsible for resolving a POID or accept a filter and respond to it with the matching entities.
From the other end: when a you decide to create a world lifespan type, you also have to take care of storing such entities and provide a service to get or find them. The type scheme will guide the runtime to your instance service - and you will have to provide and resolve the POID within your environment (you con't have to use a public service to get the next or check for collisions). You can have
- a centralized storage and a common identifier management for the type (presumably this will be the case for the dust internal types);
- have a distributed scheme, like a Person type where there should be regions created to hold the master copy of the person database and provide the next identifiers. In this case the POID contains the creator region and the user id local to that region;
- have a delegation scheme, like the type management can delegate the resolution request to the vendor of the referred type.