Has any of you migrated a large project from Realm Java to Realm Kotlin? How was your experience? Did it take a lot of effort or was it a smooth migration?
My app is currently written in Kotlin, but I am still using Realm-java. However, it does seem like a good idea to migrate and I have also noticed that the development on Realm-java is lagging behind a little (for example Realm java doesn’t support file format 23 yet whereas Realm-kotlin has done so for a month. )
No response, so I guess this hasn’t been done a lot yet. I started on the migration. Unfortunately it is a HUGE effort. Everything is changed, from threading to query language and you even need to switch out the date types used. I am sure this will simplify the code base in the long run, but it is a risky project to do a full migration. I haven’t been able to compile my project for weeks, so the risk of introducing errors is big
Hello Simon,
Best advice? wipe all the realm packages, and start the Realm components from scratch with your application if you’re going to do this.
Either way, you’re going to end up with a completely different application backend wise doing this.
I did remove the Realm Java package and replaced it with Realm Kotlin. The whole migration of my app took about a month. Some takeaways
1: Migration is completely different. Make sure you have good tests for this or you will run into trouble.
2: Testing in general is a pain with the Kotlin SDK. MongoDb has no documentation on testing and if you use the recommended way to write to the database (Realm.write) you will inevitably end up with a bunch of deadlocks in your tests. There doesn’t seem to be a way to override the default write dispatcher in your tests. I ended up using a custom write function that calls realm.write in production but realm.writeblocking in tests.
3: Database objects are no longer automatically updated. This is nice once you get the hang of it, but can lead to significant rewrites in your viewmodels
In general I think the transition will be worth it for me. The new SDK makes it easier to use coroutines and I am much more confident regarding threading than before. The code base is simpler and more consistent. For larger apps/organizations I am not sure if the migration path I took is feasible since it will completely break your app for a long long time, so make sure to have a strategy before doing the migration.
A different approach I would have done, is build a new realm app and make a secondary branch of your app and make the changes there. So then your app is fully functional and running, but you’re able to work on the new version of your app with the new SDK.
Then once you finish everything, merge it into the main branch and archive the old main branch. Then in app stores push the new update.
Not sure what you mean by creating a new Realm app, but I assume this refers to a new app on MongoDb Realm/Atlas? I only use Realm locally so far (although the plan is to eventually move to Atlas), so no need to involve the server side components at all for me. I guess the migration would be even harder for those that use sync
Hello Simon,
Yes,
Basically just cloning the main apps repo to a new repo, so your main app in production isn’t being impacted, and then just migrate on the second version of things with the new realm app using the Kotlin SDK.
@Simon_Persson Sorry it won’t let me edit my last post anymore, not sure why the edit buttons gone.
But anyways.
You have right now say:
App 1
Realm Java App1.
If you make a replica of the GitHub/GitLab repo and rename it:
App 1 clone - > App 2
Flexible Sync Kotlin App1
You can do all of your work in the cloned repo, and not even touch your app that’s in production. So your users are unaffected.
Then, when you’re done working on the Flexible sync version of your app, merge it and replace the old app using Java with your Kotlin version. Then the users who already have your app downloaded will download a “big update,” and not be the wiser at all what happened.
Then on Atlas before this, migrate all the data from one collection to the new collection, make it all the same and drop the old collection after you’re done pushing the Kotlin version of your app, and no one will ever be the wiser via user base that anything happened. But you get to have all the ample time etc. to workout and figure out your moves without having any app downtime for your users.
As mentioned. I don’t use Atlas, so no need for me to think about that, but good info for others looking to migrate 