Open question to anyone using Realm Object Server sync in production. This is tangentially related to some issues I started to see while exploring what was going on with https://forums.realm.io/t/unsupported-instruction-error-on-swift-asyncopen/950/5 .
I had neglected to notice while working on an ROS prototype that destructive migrations were essentially not supported with Realm Object Server ( or certainly heavily advised against, as per https://realm.io/docs/swift/latest/#syncing-migrations ). The instructions on that documentation page lead me to believe that the following things are true for Realm Object Server / Realm Platform:
With Realm Object Server, schema changes are very, very important to detect as they can prevent clients from initializing correctly. I say “schema changes” in the global sense, that is schema changes as broadcast by the ROS ( which I assume is an equal peer with the clients in distributed Realm ) and schema changes as implied by clients connecting to ROS.
With Realm Object Server, it’s implied that connecting clients should manage and version their access to collections themselves, in order to prevent a schema change from preventing them from moving forward. ( using the advice from the linked documentation page, namely:
Since synced Realms don’t support migration blocks, destructive changes for a migration—changing a primary key, changing field types of existing fields (while keeping the same name), or changing a property from optional to required or vice-versa—need to be handled in a different way. Create a new synchronized Realm with the new schema, and copy data from the old Realm to the new Realm:
Synchronized Realms can’t be opened in Read Only mode, which means that the schema is always mutable by any client at any time. Which means that you have to be extremely disciplined about following the advice in (2), due to the fact that any schema change can prevent any/all other clients from opening a Realm cleanly.
Schemas are (by nature of how they’re determined by N separate platforms), not really deterministic. eg, there’s no simple way for me to state that for any given Realm configuration on a platform, it will be identical to the Realm configuration on another platform. Or put another way, there’s no way for me to issue this deterministically across N platforms or versions:
CREATE realm FOO ALTER realm FOO ( name STRING, counter INT )
since the given Realm configuration for a platform is inferred by how Realm detects properties on a given class.
Are all these facts true in production? Does anyone using ROS in production run into these things if so, or are concerns / issues like this largely not important for common ROS usage?