0

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

J. S.
  • 3
  • 3

1 Answers1

0

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:.

https://github.com/drewmccormack/ensembles/blob/master/Framework/Source/Ensemble/CDEPersistentStoreEnsemble.h#L392

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.

Drew McCormack
  • 3,490
  • 1
  • 19
  • 23
  • Hi Drew, I guess that I should have stated explicitly that I do want to to maintain a plist to provide a dynamic identifier for a specific document. The reasoning being to track if a store had to be deleeched, and thus moved to another identifier or migrated to another core data model version. There are a couple of other reasons but those are the biggest. Given this requirement, how do you suggest maintaining such a registry when the information will need to be updated and, thus, changes to a file must be made. You alluded to this in your book but didn't state how it should be implemented. – J. S. Jul 30 '17 at 22:31
  • I still think you should just use the method I mentioned to get the cloud docs, and use that info to update a local plist on each device. Ie don't sync the plist. This way, you can see deletions etc. Note that you can detect an error due to model change by looking for `CDEErrorCodeUnknownModelVersion` in the `nonCriticalErrorCodes` property of `CDEPersistentStoreEnsemble` in the completion block of a merge. – Drew McCormack Aug 01 '17 at 07:00