I purchased Ensembles support almost a year ago, but sadly am only now getting around to trying to use it.
I have an application that supports multiple core data documents and am trying to ascertain the best way to discover them. In your book, you suggest that using a custom registry to support document metadata with plist files may be the best way to implement document discovery, name changes, etc. I designed a way to do this, but realized that once I went to "update" (by using the same file name with changes made and uploading to the cloud) that plist file for a document I received an error:
2017-07-26 10:54:16.986553-0700 XXX[6080:2429554] Some records failed to upload due to existing items. Usually due to out-of-date query caching on CloudKit. Will self correct. Ignoring: defaultOwner) =
This made me realize that it contradicts another problem with the design... files aren't meant to be removed and re-uploaded because then a race condition exists and you can end up with data corruption.
Was there a specific way that you thought a plist file could be updated so that you could trust the data within or should you upload new plist files with timestamped names and "hope" that the data was merged correctly.
Could you please describe, in a little more detail, your design theory for how to solve this problem for document registry with Ensembles?
Thank you, Jaime
There is actually a way to detect what documents exist without using a property list or anything like that. There is a class function on the CDEPersistentStoreEnsemble called +retrieveEnsembleIdentifiersFromCloudFileSystem:completion:.
This will return an array of ensemble identifiers via the completion handler. If you give your ensembles the same names as your document files, you should be able to figure out what exists in the cloud data without having to sync plists or anything like that.