drewmccormack / ensembles

A synchronization framework for Core Data.
MIT License
1.63k stars 132 forks source link

CDEErrorDomain Code=205 "(null)" #237

Closed basebander closed 8 years ago

basebander commented 8 years ago

Hi Drew,

I have a production app that incorporates Ensembles (via CloudKit) and I'm seeing a problem:

  1. I download my app from the App Store, turn on sync and create an entry.
  2. I give it adequate time to merge.
  3. To test it, I delete the app, then re-download it again from the App Store, I turn sync back on and wait.
  4. The entry I previously entered is synced back down to the device (as expected).

This (I believe) tells me that everything is okay with the Ensembles setup. However, I have a problem when I build the current app on top of the downloaded App Store version.

The app starts, tries to merge at startup, then fails and deleeches itself, with the error CDEErrorDomain Code=205 "(null)". I can see from the CDEDefines.h file that Error 205 means that the ensemble is no longer registered in the cloud. Can you give any insight into why that may happen when testing between production and development builds?

Output [https://gist.github.com/basebander/ef923e3b7e121745b26a084f8eb179b2]

Thank you for any help you can offer.

drewmccormack commented 8 years ago

Yes, this is an unfortunate consequence of the production/development setup. When you build with Xcode, it uses the development environment; the app store version uses production. Ensembles keeps a local cache of the cloud data, and if it notices it changed unexpectedly, it deleeches. When you move between production and development, the cloud data changes. You can think of it like a user switch in iCloud.

In my development, I just accept that this deleech will happen, and releech or nuke the cloud data. But you could setup different paths for each environment if you are really eager. The trick is to have the local cache stored at a different location for each environment. I think you could just have a custom ensemble id for each (e.g. MyStore, MyStore-Debug).

Drew

drewmccormack commented 8 years ago

Also, if you don't want to have different ensemble ids, you could make the local data folder different for each environment. There is an initialiser for CDEPersistentStoreEnsemble that allows you to pass that in:

- (nonnull instancetype)initWithEnsembleIdentifier:(nonnull NSString *)identifier persistentStoreURL:(nonnull NSURL *)storeURL persistentStoreOptions:(nullable NSDictionary *)options managedObjectModelURL:(nonnull NSURL *)modelURL cloudFileSystem:(nonnull id <CDECloudFileSystem>)cloudFileSystem localDataRootDirectoryURL:(nullable NSURL *)dataRootURL;
basebander commented 8 years ago

Ok, that makes sense. As long as that is the intended behavior and it doesn't happen to end users, it's all good. :) Thanks for your quick reply!