search

realm / realm-object-server

Tracking of issues related to the Realm Object Server and other general issues not related to the specific SDK's
https://realm.io
293 stars 42 forks source link

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

Open michael-mckenna opened 7 years ago

michael-mckenna commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

michael-mckenna commented 7 years ago

@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 commented 7 years ago

@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