Understanding the interaction between local realm, sync, Atlas using swift on iOS app

[Donal_MacCoon]

I have gone through the intro monoDB University course as well as the course on schemas. I’ve gone through the tracker tutorial and it works. I also have checked out the MongoDB twitch offerings. I am able to setup a backend that connects to my iOS app and create or sign-in a user.

I have a working local realm in an existing swift-based iOS app, and I would like users to be able to remain offline totally if they wish. If they decide to go online, I’d like MongoDB as the backend and for data to sync.

There are a few fundamental things I need to know:

(1) When I start using sync, I can no longer see my local realm using realm studio or realm browser. It wants an encryption key to allow access to the local file. I understand this has something to do with different histories between local and remote (though I haven’t successfully synced anything…see below), but it would be very useful if I could see my local realm for understanding what my CRUD operations are doing locally vs. on Atlas. Is there any way to view my local file?

(2) I don’t understand how my local realm interacts with the Atlas cluster and realmsync. For example, do I need to perform separate writes to update both the cluster and my local realm? Or, does sync take care of both the local and the remote? Do I need to have the Atlas schemas set up for all the objects in my app if I don’t need to write those? If I want to only write a subset of my realm objects to MongoDB but want the full set saved locally, how do I do that?

(3) Is there a list of error codes and what they mean somewhere? If so, I can’t find it. The lack of that resource makes it very difficult for me to learn what I’m doing wrong. For example, I’m getting the following error: Sync: Connection[1]: Session[1]: Received: ERROR(error_code=225, message_size=180, try_again=0).

Thank you.

[Ian_Ward]

@Donal_MacCoon You do not need to write to both the local realm and MongoDB if you are opening a synced Realm - we take care of all of that for you - that’s the magic! You can read more about it here:
https://docs.mongodb.com/realm/sync/overview/#think-offline-first

You do need to have your schema set up on the MongoDB Realm cloud - you define it manually here:

Configure Your Data Model — Atlas App Services

Or use developer mode (designed for mobile developers) - which defines your schema on the serverside from the mobile data model
https://docs.mongodb.com/realm/sync/enable-development-mode/

If you want to only sync some objects - one way you could accomplish this is by using both a synced realm and a non-synced realm. Any objects you don’t want to sync but store locally just store in the local realm. You would hold a reference to each separate realm? ie. localRealm and syncRealm

Error code 225 is a schema mismatch error - you can read more about it here -

Errors

We are working on porting these docs over. If you check your server logs you will see something like this:

Ending session with error: additive schema change: adding schema for Realm table "myObject", additive changes from clients are restricted when developer mode is disabled (ProtocolErrorCode=225)

[Donal_MacCoon]

Thank you so much for the helpful response. This got me past some blocked points. I’m inferring from the lack of response on being able to view local realms that one should simply check work based on the synced realm.

Also the error document you reference doesn’t appear to actually have a error code 225 but maybe I’m missing something.

Am I right in thinking that once a user goes online for the first time, the local data base will have to have their user ID number (assigned when signed up) to all the _partition variables before they will be synced appropriately on atlas?

Thanks again!

[Ian_Ward]

No you should be able to open a local synced realm. See - Fixes #392 open a local sync Realm by nhachicha · Pull Request #498 · realm/realm-studio · GitHub

Am I right in thinking that once a user goes online for the first time, the local data base will have to have their user ID number (assigned when signed up) to all the _partition variables before they will be synced appropriately on atlas?

That depends on if you assign the userId as the partitionKey value in your code. But you can do that with something like this:

 let partitionValue = app.currentUser()!.identity!
 self.realm = try! Realm(configuration: user.configuration(partitionValue: partitionValue))

[Jay (Jason Wooten)]

Let me add a bit of data we’ve found in reference to the original question # (1)

@Ian_Ward feel free to correct me but please check my findings first if I’m off.

If you are using Beta MongoDB Realm with sync, you cannot open the sync’d Realm locally with Realm Studio 3.11.0

 **Update: The documentation was incorrect and is now fixed. It must be opened with Realm Studio 10.x.**

Here’s what our findings show:

When you’re using a local Realm, or a Realm Cloud sync (5.x.x), the Realm files are stored in ~/library/application support/app name and will look like this

You can open that with Realm Studio, modify and edit it or even delete it if you want to start fresh. If deleted, the next time the app opens, it will read your Realm Objects and re-create those files.

However, when using Beta MongoDB Realm sync, there’s a different structure and then _partitions come into play.

With Beta MongoDB Realm sync’d, the files look like this (noting the above structure no longer exists as long as there are no locally stored Realm objects e.g. all sync’d.)

And while there are .realm files, they are different for each partition. In this case, note I have a Realm with an object using a Task partition and then a totally separate set of files for the objects with the Jay partition.

Note that in the web console all of those objects are stored ‘together’ visually within the same collection (the _partitionKey values are different)

If you delete the high level folder in the Finder (ending in .TaskTracker, shown above - maybe in the case of a client reset error for example) and re-run the app, that causes it to re-sync - the objects are re-sync’d only when they are accessed per partition.

In other words, our app initially only shows objects in the Tasks partition so when the app starts, those files are synced/created. From a popup, selecting that we want to view objects in the Jay partition, then those are synced/created.

The cool thing there in development is if you change an object you can just delete the objects for that _partitionKey causing it to re-sync without affecting the other objects.

So, no, local Realms cannot be managed with the current version of Realm Studio - the objects are not stored in the same way as a non-beta local Realm

Update: No as in they are not compatible with 3.11.0 but ARE compatible with Real Studio 10.x

If you want to manage your Beta MongoDB Realm that’s sync’d, it CAN be done through the MongoDB Realm web console or via Realm Studio 10.x

[Ian_Ward]

@Jay

So, no, local Realms cannot be managed with the current version of Realm Studio - the objects are not stored in the same way as a non-beta local Realm

This is incorrect. Non-sync realms and synced realm are stored in a different way on disk but that doesn’t really matter - you should still be able to open them with Realm Studio. They are stored in a different way because syncing introduces a bunch of new concepts like users, permissions, and partitioning that is not germane to a non-synced realm.

@Jay

If you want to manage your Beta MongoDB Realm that’s sync’d, it should be done through the MongoDB Realm web console.

This is not true - you should be able to open synced realms with Realm Studio in the “local” way, if it doesn’t work then there is a bug and we will fix it. Your issue looks like a file format mismatch - check the release notes for the SDK and Studio and make sure your versions are aligned.

[Jay (Jason Wooten)]

Good good, glad that info is wrong, I thought it may be as such but just wanted to paint a current picture of our experience since it’s independent of any coding issues and in case others run into the same thing - I will update it once we have clarity.

Regardless, it would be correct that every partition has its own ‘realm’ file (as shown in the screenshot), so to administer your ‘database’ with Realm Studio, you would have to open each partition separately. Not sure how that works with users in each file etc but we’ll see once it works.

Realm versions all match up. Realm Studio 3.11.0, pod ‘RealmSwift’, ‘=10.0.0-beta.4’. We’ve got the same config on several workstations and tried it with different data/files and even after a full delete and resync of everything.

Interesting to note that the Realm Studio Error message says it’s not compatible

‘with format version 11’

when that doesn’t exist yet for us; how could we have a v11 formatted Realm?

v10.0.0-beta.4

realm-ci released this 10 days ago · 4 commits to master since this release

Compatibility

• File format: Generates Realms with format v10 (Reads and upgrades all previous formats)
• Realm Studio: 3.11 or later.

and our Realm Studio

[Ian_Ward]

Those versions are incompatible. Where are you getting your information to make a statement like this:

@Jay

Realm versions all match up. Realm Studio 3.11.0, pod ‘RealmSwift’, ‘=10.0.0-beta.4’.

I’d like to correct that doc if you are reading it somewhere

[Jay (Jason Wooten)]

@Ian_Ward

That link was to the release notes. Go here and scroll down a tad to the the v10.0.0-beta.4 section

Releases · realm/realm-swift

[Ian_Ward]

Oofh - yeah looks like some of these are wrong. I’ll get that corrected. You need to use a 10.x version of Studio - the reason we bumped all SDKs to 10 was to make compatibility clear

[Jay (Jason Wooten)]

@Ian_Ward

Fantastic! Super good info and we’ll get everything updated. Thanks for the help and clarification.

[Donal_MacCoon]

Thank you both for leading a conversation I could not contribute much to but am gaining benefit from.