Hello! I am very excited about the new Apollo Kotl...

# apollo-kotlin

[Eduard Boloș]

Hello! I am very excited about the new Apollo Kotlin, and I was looking at what it would take to upgrade the project from work from v2 to v3, but unfortunately it seems like a migration would be extremely difficult, from what I could tell so far. Even if using codegenModels set to compat, or with `useVersion2Compat()`(which I think that it might do the same thing), there would be thousands of changes to go through in the project, the vast majority of them would be just removing function invocations from GQL fields, quite a few of them would be changing how polymorphic fragments are accessed, and a lot of mutation and query builders need to be changed too to constructor invocations. It would be a huuuuge time sink to do all of this changes in one go, so I was wondering, is it possible to have v2 and v3 running side by side in the same app, but using the same SQL cache? So that we can keep the old code using Apollo-Android, and slowly migrate to Apollo-Kotlin. (This would actually solve another issue for us, we have a lot of custom code that allows us to pass references to fragments from one activity to another and then observe for updates, and we would have to rewrite most of it, but again, it's hard to do it in one go. Thankfully, ApolloStore.readFragment() from v3 does a lot of this already 😄.)
I imagine that even if it would be possible to have two instances writing to and reading from the same database, observing the cache for updates using .watch() won't trigger any updates if the write was done by the other instance, isn't it?
Is there any hope to ease the migration for such a complex project? I want the new and fancy test builders, haha. (Sorry for the wall of text.)

[mbonnin]

Using apollo2 and apollo3 side by side is possible but sharing the cache is not unfortunately. Mainly because locking would have to be shared and like you said, watch would come with challenges too

[mbonnin]

From what you're saying, looks like you're migrating from java models? compat models are compatible with Kotlin codegen (with a few exceptions) but have a lot more differences with Java models

[mbonnin]

If that's the case, you can as an intermediate step, enable Kotlin models in your apollo2 codebase (generateKotlinModels.set(true)).

[mbonnin]

Another option is to write a script that does this automatically. Most of the changes are automatic enough so that they could be scripted

[Eduard Boloș]

Yes, we're still using Java models 😞 Indeed, migrating first to Kotlin models sounds like it would ease the migration. Thanks for the pointers, Martin! 🙂