New: Foreign key constraints and flexible primary keys

[mbrandonw]

Important

The changes released today are breaking and may be incompatible with CloudKit containers created for earlier versions of the alpha. If you experience any issues with the update, try rotating your CloudKit container to a fresh one to see if the issue is resolved.

Hi all, it’s been a little over week since our last update concerning the CloudKit private alpha, and we have implemented a few new powerful features since then.

Foreign key constraints are now supported

When we first started working on these tools we did not think it would be possible to enforce foreign key integrity in the client database. After all, your data is now distributed across many devices, and so it is possible to receive records in any order. You could receive a Reminder at one moment, and then the RemindersList it belongs to a few seconds later, and so if FK constraints are enabled, how can that work?

Well, with this PR we now allow foreign key constraints. Whenever we detect that an upsert of the local database with a server record failed, we cache that server record so that it can be tried again when a new batch of data comes in from CloudKit. And so in the above scenario, we would cache the Reminder record, and then when the RemindersList is delivered we will try to insert the Reminder again after the RemindersList. Further, we are able to use the FK relationships you supply in your schema to perform a topological sort on the tables so that we make sure to always insert parent records before attempting to insert child records.

Flexible primary keys

In the first release of our alpha we required that all primary keys of tables synchronized to CloudKit must be of type UUID. This is because newly created records must have globally unique IDs, but the requirement of literally UUID was overly restrictive. Some people want to use other forms of global identifiers (such as UUIDv7), and others want to wrap their IDs in a type-safe package, such as Tagged.

So we relaxed this requirement and now only require that your primary key conform to the IdentifierStringConvertible protocol. It is still highly, highly recommended that you use a globally unique identifier, such as some version of UUID. But now you can use different types of identifiers.

---

Please let us know if you have any questions or feedback, and as always thanks for helping us alpha test these tools. We hope to open a public beta in the coming weeks.