Adios PK1 Persistent IDs

Blog Post created by mkauffman on Dec 5, 2018

In previous Learn APIs (Java and SOAP) the database Primary Key served as a means of identifying Learn Objects. These Primary Keys, or PK1s, are used internally to the Learn system, but are no longer viable as unique identifiers for the objects bound to that database specific identifier.


As we continue rolling out our REST APIs we're working to improve API reliability and the longevity of applications build using them. Part of that decision is a move away from facilitating API use of PK1s as a means of accessing objects via the database primary key, i.e. the PK1, often referenced as the object's id in our APIs and REST results.


There are many compelling reasons for this decision, including creating a loose coupling between the Learn internal database and external code, thereby avoiding issues that inevitably arise when a system is migrated. Migrating a systems database generates new Primary Keys for the object data migrated, and thus created in the new database - this is a characteristic of databases. We may continue to include PK1s in REST results for Courses and Users for use in requests as a convenience*, but these PK1s should never be used as permanent external identifiers of Learn objects.


One example of this change as several have pointed out, is the difference between the soon-to-be deprecated SOAP and our REST membership endpoints. With SOAP calls to the CourseMembership endpoint returned a CourseMembershipVO that contained a field 'id' which is the PK1/ID. That data point is not available from the REST membership endpoints. This is because we have eliminated the id/PK1 field from the response returned by the REST GET/learn/api/public/v1/courses/{courseId}/users endpoints to meet the above stated goals toward reliability and longevity.


What do you use instead of the PK1?

What may have seemed like a good, solid identifier really is not. The way forward is to start using the different objects' UUIDs as returned in REST requests.


You need to replace any use of PK1 or ID as the unique identifier, whether using SOAP or Java APIs. When migrating your application to using REST APIs you may use a lazy identifier migration. In this model you may add the UUID field to your database and populate as you access those objects at runtime. If your code finds your UUID fields empty when making a Learn access, you use the courseID and userName you have to look up the UUID for the course membership, the UUID for the course, and the UUID for the user and populate those fields. Doing it this way eliminates the need for one mass migration, you get the new data as you go. If you see other creative means forward, please share here.


In summary, now is the time to start moving away from using API functionality that uses a PK1 or Database dependent object IDs and move to using the object’s UUID.


  *Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.