I currently have a realm app in production using partitioned sync (Swift). I am planning on transitioning and releasing an update of the app on the App Store that will open the realm and sync using flexible sync.
Ideally, I would like to still support sync for users who are on the current version of the app (running partition sync), until they update to the newer version of the app running flexible sync.
If I have not specified in the codebase of the current version of the app to open and sync using flexible sync, how may you suggest I continue supporting syncing in the current version of the app when I terminate (partition) sync and re-enable (flexible) sync?
After further consideration, I’m thinking the only way I may be able to do this is by creating another app in App Services (which uses flexible sync), linking the existing atlas cluster to the new app and subscribing to the partition value, used for the current app.
The only problem I can see in doing this comes when creating/authenticating users in the new flexible sync app. When a user is authenticated for the first time, app services stores the new user, with a new id, which will not be the same id as that given to the same user in the current version of the app.
Fortunately, I have stored the partition value in the Keychain, so I am able to subscribe to the correct partition value. This however, does not fix the issue of realm storing users with a new id value, which obviously has complications when it comes time to issuing permissions.
Further, when employing a second app to assist in solving this problem, I would like to sync the user’s current data stored in atlas back down to the newly created local realm on the user device.
I’m still unable to find any help or guidance on this by the MongoDb team so unless anyone else has any thoughts/opinions to contribute (ANY HELP IS APPRECIATED), I’ll continue to post my progress here.
@BenJ Hey there. We are working on a feature right now that will allow in-place migrations to flexible sync without needing to create a separate app and hopefully without changes to your client side code. We hope to have an initial version in the next quarter.
To migrate yourself manually, yes, the procedure would be as you describe where you would create a new Device Sync app and attach it to the same Atlas cluster. You would then release a new version of the client app which has new the new app id and would sync via flexible sync APIs. Users would need to re-authenticate however which is why you’d want to abstract away your permissions and store it in some other format so that the same permissions and therefore the same data would be synced down to the client. We would recommend something like custom JWT with a 3rd party provider, custom user data, or a function auth.
Hi @Ian_Ward, do you have any update regarding the release of this in-place migration to flexible sync?
I’ve been an early adopter of the partition sync since its release and I’m using it in production. I have noticed the new “automatic client reset” feature - which is a godsend - but the doc only shows how to do this for flexible sync. I’m keen to migrate my app to flexible sync for that reason. I also think it’s the right direction for sync to move towards.
Hey all - support for a backwards-compatible migration from partition-based to flexible sync is now available! Note that there is a realm SDK component to this, so you’ll need to ensure that your end-users are on the latest version of the SDK in order to support connecting to the migrated app.
Thanks for update @Kiro_Morko, and for all the hard work that must have gone into this! If I read the docs correctly, this migration is not yet available for the React Native SDK? Any rough idea when this may become available?
Hi @Ian_Ward,
I have 2 questions regarding the in-place migration.
What happens to the users who still use the current version of the app (i.e. the partition-sync). Will the app still work in partition-sync mode even though the app service has been migrated to flexible-sync configuration?
Why I ask this is because, according to the Swift SDK I open a sync realm using flexibleConfiguration for the newer apps as mentioned. So I feel that apart from how I open the synced realm and specifying the subscriptions no other change would be required at client side of the code when I’m configuring flexible sync after doing the in-place migration.
Your input would be really helpful regarding these two doubts that I have.
The migrator feature works without any SDK changes required - it simply changes the backend logic to flexible sync and interprets and partition-based sync queries as flexible. Of course, you should test this before rolling out to production.
I would also note that older SDKs don’t automatically work with the migration. You’ll need to make sure your users have upgraded to a minimum version. For instance, if you’re using the Swift SDK, you’ll need a minimum version of 10.40.0. I have a production app where I have never made it mandatory to update and am waiting till most of my users are on an upgradable version before going ahead with the migration just to reduce the amount of customer support that will happen for those still running the older versions.
- but the doc only shows how to do this for flexible sync. I’m keen to migrate my app to flexible sync for that reason. I also think it’s the right direction for sync to move towards.