libs-gscoredata/Documentation/NSManagedObjectID.txt
H. Nikolaus Schaller 30c88829fc New Import
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep@25765 72102866-910b-0410-8b05-ffd578937521
2007-12-20 08:39:55 +00:00

77 lines
2.8 KiB
Text

IMPLEMENTATION NOTES FOR THE NSManagedObjectID CLASS
----------------------------------------------------
There are two principal kinds of managed object IDs:
- Temporary IDs. An NSManagedObject is assigned a temporary ID when
it is created.
- Permanent IDs. Managed objects with temporary IDs are re-assigned
a permanent ID when they are saved to a persistent store.
Both IDs are composed of two pieces of information:
- a large (64-bit) unsigned integer, called the value of the ID.
- a store URL to which (from which) the object the ID describes is
stored (fetched).
Temporary IDs don't contain the latter value.
TEMPORARY ID GENERATION
-----------------------
When a new temporary object ID is generated, Core Data uses an internal
counter to always assign the ID a new unique value - the counter is
afterwards incremented, so that when a new ID is created it is assigned,
again, a unique value.
PERMANENT ID GENERATION
-----------------------
The same approach as with temporary IDs may not, however, be used when
creating permanent IDs, since there may already be IDs with certain
values in the store. Instead, each store stores a special `highest ID
value' which denotes the highest ID value of any ID in the store. So
when a permanent ID is created for a given persistent store, the ID is
assigned the `highest ID value + 1' and the highest ID value is
incremented.
Additionally to this, permanent object IDs have the store URL assigned
to which they belong. And thus permanent object ID value uniqueness is
scope to the single store to which they belong.
HOW DO WE ENSURE WE WON'T RUN OUT OF ID VALUES?
-----------------------------------------------
By terms of simple maths: imagine 10000 computers were generating 10000
object IDs every second. It would take them almost 6000 years to exhaust
the interval of the 64-bit integer used for permanent object IDs.
Temporary IDs also have an unsigned 64-bit value, but they live in a
different number space and don't clash with permanent IDs - each
permanent ID value is scoped only to the persistent store where it comes
from. This kind of heavy usage simply isn't realistic.
MANAGED OBJECT URI-REPRESENTATION STRUCTURE
-------------------------------------------
A managed object ID can be transformed into an archivable URI
representation so that programs can later refer to a certain object.
Only permanent managed object IDs can be represented as a URI, temporary
ones simply return `nil'. The URI looks like this:
"<StoreUUID>/<EntityName>/<IDValue>"
Where:
StoreUUID - is the UUID of the persistent store where the ID belongs.
EntityName - the name of the entity of the object the ID identifies.
IDValue - the value of the ID in hexa.
Example:
"EE4F9FA7DC9D8322A0255FED602EA7FC60B84CBE6475F5B1F22E7D0B48C38BE1/Department/B955DB7"