I am using CloudKit Sharing and am having an issue deleting records. I create two records: an Entry and an Asset. If I set the .parent of the Asset to point to the Entry, then when I attempt to delete both the Entry and the Asset in the same batch, it fails with a reference violation error:
<CKError 0x600002ac2190: \"Reference Violation\" (31/2025); server message = \"Record delete would violate validating reference ([a1]), rejecting update\"
Details
I create a parent record (Entry) and a child record (Asset), and set the Asset's .parent to the Entry:
let eid = CKRecord.ID(recordName: "e1", zoneID: CKRecordZone.ID(zoneName: "test", ownerName: CKCurrentUserDefaultName))
let e = CKRecord(recordType: "Entry", recordID: eid)
e["title"] = "Entry"
let aid = CKRecord.ID(recordName: "a1", zoneID: CKRecordZone.ID(zoneName: "test", ownerName: CKCurrentUserDefaultName))
let a = CKRecord(recordType: "Asset", recordID: aid)
a["position"] = 1
a.setParent(e)
Then I save both in the same call:
let op = CKModifyRecordsOperation(recordsToSave: [e,a], recordIDsToDelete: nil)
op.modifyRecordsCompletionBlock = { (records, recordIDs, error) in
print("Returned from modify")
print("records: \(records)")
print("error: \(error)")
}
CKContainer.default().privateCloudDatabase.add(op)
The operation completes successfully and the records are properly created in CloudKit.
But, when I attempt to delete both:
let op = CKModifyRecordsOperation(recordsToSave: nil, recordIDsToDelete: [eid, aid])
op.modifyRecordsCompletionBlock = { (records, recordIDs, error) in
print("Returned from modify")
print("records: \(records)")
print("deleted: \(recordIDs)")
print("error: \(error)")
}
CKContainer.default().privateCloudDatabase.add(op)
I get the above error.
Work Arounds
I realize that I could delete the Asset first, and when that returns, delete the Entry. But, my remote management code batches many things together and I don't want to re-work it figure out which things to do first, and I want to minimize the number of remote calls I need.
I've also discovered that if I add another field to the Asset record that references the Entry with a .deleteSelf action, this all works. So, in the above code where I create the Asset, if I add the following (while keeping the setParent() call:
a["entryRef"] = CKRecord.Reference(record: e, action: .deleteSelf)
Then all works correctly.
But, why should I need to create another field I don't need? I would think that sending the deletions in a single call would let CloudKit handle the references properly, without the need for this extra field.
Has anyone experienced this or found a way to work around it without needing the extra reference field? Using CKRecord.References imposes a limit of 750 references on the parent, and I'd rather not have that limit.
I realize this question is relatively old, but I ran into the same situation a bit ago, stumbled on this question, and only after some very intense observation did I find an answer which I think is worth sharing:
CKModifyRecordsOperation(recordsToSave: nil, recordIDsToDelete: [aid, eid])
Instead of supplying the parent (eid) first in the deletion array, you should supply the child (aid) first. CloudKit will then successfully process the parent-child deletion in a single batch.
I have a similar situation where my deletions are being collected without regard to the hierarchical order, so when this error is thrown, I rearrange the deleted record ID's by keeping all batch atomic failed operations (i.e., successful deletes) at the top of the array (keeping those same order!) and then move any reference violations to the bottom. Finally, I rerun the query in a loop until everything is resolved.
If there's several hierarchical records out of order, it might take some back and forth with CloudKit to finally get them together, but as long as the atomic batch failures are kept in order and each cycle resolves a reference violation, it'll eventually get there.
I've filed feedback, but seeing as this has been an issue for a LONG time, I don't see it being solved any time soon.
Related
I am using CloudKit to store publicly available data and the new NSPersistentCloudKitContainer as part of my Core Data stack to store/sync private data.
When a user opens my app, they are in 1 of 4 states:
They are a new user with access to iCloud
They are a returning user with access to iCloud
They are a new user but do not have access to iCloud for some reason
They are a returning user but do not have access to iCloud for some reason
States 1 and 2 represent my happy paths. If they are a new user, I'd like to seed the user's private store with some data before showing the initial view. If they are a returning user, I'd like to fetch data from Core Data to pass to the initial view.
Determining new/old user:
My plan is to use NSUbiquitousKeyValueStore. My concern with this is handling the case where they:
download the app -> are recorded as having launched the app before -> delete and reinstall/install the app on a new device
I assume NSUbiquitousKeyValueStore will take some time to receive updates so I need to wait until it has finished synchronizing before moving onto the initial view. Then there's the question of what happens if they don't have access to iCloud? How can NSUbiquitousKeyValueStore tell me if they are a returning user if it can't receive the updates?
Determining iCloud access:
Based on the research I've done, I can check if FileManager.default.ubiquityIdentityToken is nil to see if iCloud is available, but this will not tell me why. I would have to use CKContainer.default().accountStatus to learn why iCloud is not available. The issue is that is an asynchronous call and my app would have moved on before learning what their account status is.
I'm really scratching my head on this one. What is the best way to gracefully make sure all of these states are handled?
There's no "correct" answer here, but I don't see NSUbiquitiousKeyValueStore being a win in any way - like you said if they're not logged into iCloud or don't have network access it's not going to work for them anyway. I've got some sharing related stuff done using NSUbiquitiousKeyValueStore currently and wouldn't do it that way next time. I'm really hoping NSPersistentCloudKitContainer supports sharing in iOS 14 and I can just wipe out most of my CloudKit code in one fell swoop.
If your app isn't functional without cloud access then you can probably just put up a screen saying that, although in general that's not a very satisfying user experience. The way I do it is to think of the iCloud sync as truly asynchronous (which it is). So I allow the user to start using the app. Then you can make your call to accountStatus to see if it's available in the background. If it is, start a sync, if it's not, then wait until it is and then start the process.
So the user can use the app indefinitely standalone on the device, and at such time as they connect to the internet everything they've done on any other device gets merged into what they've done on this new device.
I struggled with this problem as well just recently. The solution I came up with was to query iCloud directly with CloudKit and see if it has been initialized. It's actually very simple:
public func checkRemoteData(completion: #escaping (Bool) -> ()) {
let db = CKContainer.default().privateCloudDatabase
let predicate = NSPredicate(format: "CD_entityName = 'Root'")
let query = CKQuery(recordType: .init("CD_Container"), predicate: predicate)
db.perform(query, inZoneWith: nil) { result, error in
if error == nil {
if let records = result, !records.isEmpty {
completion(true)
} else {
completion(false)
}
} else {
print(error as Any)
completion(false)
}
}
}
This code illustrates a more complex case, where you have instances of a Container entity with a derived model, in this case called Root. I had something similar, and could use the existence of a root as proof that the data had been set up.
See here for first hand documentation on how Core Data information is brought over to iCloud: https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/reading_cloudkit_records_for_core_data
to improve whistler's solution on point 3 and 4,
They are a new user but do not have access to iCloud for some reason
They are a returning user but do not have access to iCloud for some reason
one should use UserDefaults as well, so that it covers offline users and to have better performance by skipping network connections when not needed, which is every time after the first time.
solution
func isFirstTimeUser() async -> Bool {
if UserDefaults.shared.bool(forKey: "hasSeenTutorial") { return false }
let db = CKContainer.default().privateCloudDatabase
let predicate = NSPredicate(format: "CD_entityName = 'Item'")
let query = CKQuery(recordType: "CD_Container", predicate: predicate)
do {
let items = (try await db.records(matching: query)).matchResults
return items.isEmpty
} catch {
return false
// this is for the answer's simplicity,
// but obviously you should handle errors accordingly.
}
}
func showTutorial() {
print("showing tutorial")
UserDefaults.shared.set(true, forKey: "hasSeenTutorial")
}
As it shows, after the first time user task showTutorial(), UserDefaults's bool value for key "hasSeenTutorial" is set to true, so no more calling expensive CK... after.
usage
if await isFirstTimeUser() {
showTutorial()
}
I am in process in adding CloudKit to my app to enable iCloud sync. But I ran into problem with my method, that executes query with perform method on private database.
My method worked fine, I then changed a few related methods (just with check if iCloud is available) and suddenly my perform method does nothing. By nothing I mean that nothing in perform(query: ) closure gets executed. I have breakpoint on the first line and others on the next lines but never manage to hit them.
private static func getAppDetailsFromCloud(completion: #escaping (_ appDetails: [CloudAppDetails]?) -> Void) {
var cloudAppDetails = [CloudAppDetails]()
let privateDatabase = CKContainer.default().privateCloudDatabase
let query = CKQuery(recordType: APPID_Type, predicate: NSPredicate(format: "TRUEPREDICATE"))
privateDatabase.perform(query, inZoneWith: nil) { (records, error) in
if let error = error {
print(error)
completion(nil)
} else {
if let records = records {
for record in records {
let appId = record.object(forKey: APPID_ID_Property) as? Int
let isDeleted = record.object(forKey: APPID_ISDELETED_Property) as? Int
if let appId = appId, let isDeleted = isDeleted {
cloudAppDetails.append(CloudAppDetails(id: appId, isDeleted: isDeleted == 1))
}
}
completion(cloudAppDetails)
return
}
}
completion(nil)
}
}
My problem starts at privateDatabase.perform line, after that no breakpoints are hit and my execution moves to function which called this one getAppDetailsFromCloud. There is no error...
This is my first time implementing CloudKit and I have no idea why nothing happens in the closure above.
Thanks for help.
EDIT: Forgot to mention that this metod used to work fine and I was able to get records from iCloud. I have not made any edits to it and now it does not work as described :/
EDIT 2: When I run the app without debugger attached then everything works flawlessly. I can sync all data between devices as expected. When I try to debug the code, then I once again get no records from iCloud.
In the completion handler shown here, if there's no error and no results are found, execution will fall through and quietly exit. So, there are two possible conditions happening here: the query isn't running or the query isn't finding any results. I'd perform the following investigative steps, in order:
Check your .entitlements file for the key com.apple.dev.icloud-container-environment. If this key isn't present, then builds from xcode will utilize the development environment. If this key is set, then builds from xcode will access the environment pointed to by this key. (Users that installed this app from Testflight or the app store will always use the production environment).
Open the cloudkit dashboard in the web browser and validate that the records you expect are indeed present in the environment indicated by step 1 and the container you expect. If the records aren't there, then you've found your problem.
If the records appear as expected in the dashboard, then place the breakpoint on the .perform line. If the query is not being called when you expected, then you need to look earlier in the call stack... who was expected to call this function?
If the .perform is being called as expected, then add an else to the if let record statement. Put a breakpoint in the else block. If that fires, then the query ran but found no records.
If, after the above steps, you find that the completion handler absolutely isn't executed, this suggests a malformed query. Try running the query by hand using the cloudkit dashboard and observing the results.
The closure executes asynchronously and usually you need to wait few seconds.
Take into account you can't debug many threads in same way as single. Bcs debugger will not hit breakpoint in closure while you staying in your main thread.
2019, I encountered this issue while working on my CloudKit tasks. Thunk's selected answer didn't help me, so I guess I'm gonna share here my magic. I got the idea of removing the breakpoints and print the results instead. And it worked. But I still need to use breakpoints inside the closure. Well, what I had to do is restart the Xcode. You know the drill in iOS development, if something's not right, restart the Xcode, reconnect the device, and whatnot.
I am having issues deleting CloudKit records. This is my first time dealing with the API and apparently there are two ways to do this.
Saving records is straight forward and ostensibly so is deleting them, except this doesn't do it:
func deleteRecords() {
let recordID = record.recordID
publicDatabase.delete(withRecordID: recordID) { (recordID, error) in
guard let recordID = recordID else {
print(error!.localizedDescription)
return
}
print("Record \(recordID) was successfully deleted")
}
}
I understand using a ckModifyRecordsOperation is another way to do this but this is a batch operation. I only need to delete one record at a time. Here's my code for that:
func batchDelete() {
let recordIDsToDelete = [CKRecordID]()
let operation = CKModifyRecordsOperation(recordsToSave: nil, recordIDsToDelete: recordIDsToDelete)
operation.modifyRecordsCompletionBlock = { savedRecords, deletedRecordIDs, error in
// handle errors here
}
publicDatabase.add(operation)
print("Batch \(recordIDsToDelete) record was successfully deleted")
}
Neither of these separately or together are working for me.
You are correct, there are two ways. The first way you describe is referred to by Apple as a "convenience" function. If you're just deleting a single record, it's probably the quickest option to implement. However, each convenience operation conducts its own trip to the database. If you loop through thousands of records and delete them individually with the convenience function, you're going to use a lot of your cloudKit quota making a series of individual calls.
The second option, the operation, let's you batch the deletes and send them in one operation. Generally, this will be a more efficient use of your cloudkit quotas. But, according to Apple docs, there's no technical difference between the two; the the convenience function is just a wrapper to the operation.
Now, to your specific problem, the operation has two separate completion blocks: perRecordCompletionBlock and modifyRecordsCompletionBlock. As the names imply, the first block is called after each and every record is processed in the operation and that's where errors are surfaced. Make sure you implement perRecordCompletionBlock and check for errors there (and then you'll have to decide if your error handling steps belong in the perRecordCompletionBlock or the modifyRecordsCompletionBlock).
Finally, if the operation (or convenience function) is running and you confirm that the completion blocks fire without errors but the record still doesn't delete, this typically indicates you passed nil rather than a valid record to the deletion.
Both on simulator and my real device, an array of strings is saved upon app termination. When I restart the app and fetchRequest for my persisted data (either from a viewDidLoad or a manual button action), I get an empty array on the first try. It isn't until the second time I fetchRequest that I finally get my data.
The funny thing is that there doesn't seem to be a time discrepancy involved in this issue. I tried setting various timeouts before trying to fetch the second time. It doesn't matter whether I wait 10 seconds to a minute -- or even immediately after the first fetch; the data is only fetched on the second try.
I'm having to use this code to fetch my data:
var results = try self.context.fetch(fetchRequest) as! [NSManagedObject]
while (results.isEmpty) {
results = try self.context.fetch(fetchRequest) as! [NSManagedObject]
}
return results
For my sanity's sake, here's a checklist:
I'm initializing the Core Data Stack using boilerplate code from Apple: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/InitializingtheCoreDataStack.html#//apple_ref/doc/uid/TP40001075-CH4-SW1
I'm putting my single DataController instance in a static variable at the top of my class private static let context: NSManagedObjectContext = DataController().managedObjectContext
I'm successfully saving my context and can retrieve the items without any issue in a single session; but upon trying to fetch on the first try in a subsequent session, I get back an empty array (and there lies the issue).
Note** I forgot to mention that I'm building a framework. I am using CoreData with the framework's bundle identifier and using the model contained in the framework, so I want to avoid having to use logic outside of the framework (other than initalizing the framework in the appDelegate).
The Core Data stack should be initialized in applicationDidFinishLaunchingWithOptions located in appDelegate.swift because the psc is added after you're trying to fetch your data.
That boilerplate code from Apple includes:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) {
/* ... */
do {
try psc.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: storeURL, options: nil)
} catch {
fatalError("Error migrating store: \(error)")
}
}
The saved data isn't available until the addPersistentStoreWithType call finishes, and that's happening asynchronously on a different queue. It'll finish at some point but your code above is executing before that happens. What you're seeing isn't surprising-- you're basically looping until the async call finishes.
You need to somehow delay your fetch until the persistent store has been loaded. There are a couple of possibilities:
Do something sort of like what you're already doing. I'd prefer to look at the persistent store coordinator's persistentStores property to see if any stores have been loaded rather than repeatedly trying to fetch.
Post a notification after the persistent store is loaded, and do your fetch when the notification happens.
I've getting intermittent results on deletion. Sometimes the objects will delete, but most the time when I restart the project or even directly after the delete code, the store still pulls up instances of the objects. I'm deleting through a reference to managedObjectContext from the AppDelegate and making sure I save post delete.
if let object = getById(id, context: context){
context.deleteObject(object)
do{
print("Deleteing object by id")
try context.save()
}catch{
print("Unable to delete object for some reason")
}
}
If I run a getById() with the same id again right after I've successfully saved my deletion, it finds the object again. The error block never triggers, so I figure there is something else going wrong here. Any ideas where to look?
I think you are deleting the found object before entering the do loop and the context.save() is saving it back. That is probably the reason the Error block is not triggering when you look for the object.
try -
if let object = getById(id, context: context) {
do {
try context.deleteObject(object)
try context.save() (I am still not sure if this statement should be there!!!)
print()
}catch{
print()
}
}
Hope that helps.
Figured it out. Deleting was always working fine, the problem was that the identifiers to which I was fetching in my getById() method were not always unique. This caused intermittent deleting to occur because if there were 7 objects with id 1, than there was a 1/7 chance the first object was in fact the one I wished to be deleted.
Long story short, examine the whole problem, and don't make assumptions unless your sure in my case here, that the getById() was actually returning the desired object.