Changes After Deletes (or, Reusing RefId Values)
As of the US SIF 2.7M specification, RefId values now appear as an attribute in every data model object. Before discussing how they must be used, let's look at the definition from Section 3.3.3 of the US SIF specification:
Objects often carry an attribute that identifies a particular object instance; this attribute is named RefId. It is imperative that RefIds not clash with any other RefId. This is especially relevant when an agent manages a database comprised of a mix of objects; for example, a library database containing patrons, which are a mix of both students and staff.
To virtually eliminate the possibility of duplicate object identifiers and to provide a consistent, decentralized way of generating these identifiers, SIF requires the use of a globally unique identifier (GUID) that MUST be generated per published algorithms [RFC 4122] whenever a RefId is used.
How RefIds Are to be Used
As defined by the specification, Refid values are associated with an instance of an object. So, if they are associated with an instance of a StudentPersonal object that describes characteristics of a student "Barnaby Wilde", events can be generated as follows:
- Add event
- Change events (0 or more)
- Delete event
After a Delete event has been sent for that RefId, that RefId value can never be used again. If the publishing application needs to create another StudentPersonal object that holds characteristics for that student, the new object should have a new RefId value.
Given this, Delete events should normally not be sent for most objects unless either a mistake has been made in sending it originally and it needs to be replaced or if the intention is to delete it forever. If those are not the intention, then a Change event should be sent instead. Delete events are for permanently deleting the object and the RefId value.
Extreme care should be taken when deleting an object of any kind. Unfortunately, once in a while, something may be deleted by mistake. In that case, when an out of the ordinary error must be corrected, wait for an hour or more after the Delete event and then send an Add event. This should never be a regular practice, but it is a work around for cases where human error caused a delete of one or more objects in a string of highly linked objects and a RefId must be preserved.
- RefId values should never be calculated based on the value of data in an application database field. Never. Ever. No Exceptions. See Creating and Using RefId Values for more information and instructions on how to properly create RefId values.
- If an object does not exist, an application should send an Add event before it sends a Change event for it.