New: Foreign key constraints and flexible primary keys #103
              
                
                  
                  Pinned
              
          
                  
                    
                      mbrandonw
                    
                  
                
                  started this conversation in
                CloudKit Preview
              
            Replies: 0 comments
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
        
    
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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
Reminderat one moment, and then theRemindersListit 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
Reminderrecord, and then when theRemindersListis delivered we will try to insert theReminderagain after theRemindersList. 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 literallyUUIDwas 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 asTagged.So we relaxed this requirement and now only require that your primary key conform to the
IdentifierStringConvertibleprotocol. 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.
Beta Was this translation helpful? Give feedback.
All reactions