Make ROS robust to clients making destructive schema changes. Possibly prevent those in clients.

[michael-mckenna]

Asked this question in Slack and Stack Overflow (https://stackoverflow.com/questions/44621248/how-do-i-handle-realm-object-server-dying-after-accidentally-performing-a-migrat) but to no avail so I'm bringing the issue here.

Made the mistake of performing a migration on a synchronized realm, which I just now learned I shouldn’t have done according to the docs' statement “However, if the migration makes a destructive change, the Realm will stop syncing with ROS, producing a Bad changeset received error”. Since then we have nuked ROS and started over...however this obviously isn't a long term solution.

Expected Results

If the magnitude of this migration is so severe, I'd expect their to be compiler error/warning. Also I feel like instead of killing ROS as seen in our log statement realm-object-server dead but pid file exists, it'd make more sense to just disable the migration from happening and report an error. Just food for thought. It would've been really ugly if this happened in Production.

Steps to Reproduce

Perform a Realm Configuration migration on a synchronized realm

Code Sample

let config = Realm.Configuration(syncConfiguration: SyncConfiguration(user: curUser, realmURL: RealmURL.userObjects), migrationBlock: { (migration, schema) in // todo })

Version of Realm and Tooling

Realm framework version: 2.8.3

Realm Object Server version: 1.7.6

Xcode version: 8.3.3

iOS/OSX version: iOS 10.3.2

Dependency manager + version: Cocoapods, 1.2.1

[bmunkholm]

@michael-mckenna Thanks for the suggestion! The server should surely not be affected by the destructive migration, and we should try to prevent the client from making such a migration.

[bigfish24]

@michael-mckenna can you explain what changes to the schema led to this?

[michael-mckenna]

@bigfish24 Unfortunately I don't remember exactly. I was in the middle of doing some model changes then all of the sudden it happened. When it first happened, I had no idea it was because I was changing the models so I didn't make note of the changes I was making :/. I remember it was around the time we decided to change our "id" primary key attribute to a string instead of an int. Sorry for the lack of information. One of my devs triggered this recently so I will get with him on how he did it.

[bigfish24]

@michael-mckenna ok well that is actually quite helpful info! You cannot change the primary key of a model with a synced Realm. This is because we consider this a "destructive schema" change meaning it is not backwards compatible with older clients. As a result, you have to move to a new model, such as going from MyClassV0 to MyClassV1 and you can remove the definition of MyClassV0 from your application code (note the underlying synced Realm will still contain a table for MyClassV0 to maintain backwards compatibility but this doesn't have any affect on performance related to the new model.

More info on synced migrations here: https://realm.io/docs/swift/latest/#syncing-migrations