If anyone using androidx datastore, how do you tac...

# multiplatform

[Joel Denke]

If anyone using androidx datastore, how do you tackle migrating values between app updates in iOS and Android? From what I recall that not working in androidx datastore core?
If not working, does other KMP libraries offer this?

[Jeff Lockhart]

For unstructured schemaless databases, there are various ways your code can handle performing migrations. This would be similar in my own database library, Kotbase. The strategy depends on your data and goals.

Some examples include:
• For added fields, using a default value to fallback to.
• Lazy migration, values are checked on access and migrated when necessary.
• Schema version stored in a document, checked on access and migrations run as necessary.
• Migration flags in the database, queried on app start and migrations run on all documents as necessary.
If you could describe what sort of data migration you're needing to do, it might be clearer which strategy might work best.

[Joel Denke]

Its more in general, like SharedPreferences, want automatic transfer between app updates in both Android and iOS. Want as much auto magic as possible.

[Jeff Lockhart]

What do you mean by "automatic transfer between app updates"?

[Joel Denke]

Data stored in app is still stored after update from app version x to version y.

[Jeff Lockhart]

Any data persisted to the application sandbox should still exist untouched after an app update, on both Android and iOS. This should include a datastore or database instance. Are you not finding this to be the case?

[Joel Denke]

Its only the case if using androidx datastore on Android but not in iOS I think.

[Jeff Lockhart]

I would expect data persisted to datastore to persist between app updates on both Android and iOS.

[Jeff Lockhart]

If you're not finding this to be the case for datastore, you could try Kotbase, which definitely persists its databases between app updates. It's a JSON document database and supports key/value, as well as SQL and full-text search queries.

[Joel Denke]

Then I can just stick with sqdelight which already using :) Looking for a basic thing complement it.

[Jeff Lockhart]

I consider Couchbase Lite, the database Kotbase is built on, to be quite a bit simpler than SQLite. It's as simple or as powerful as you choose to use the features for it. It doesn't require a schema definition. In it's simplest form, construct a database with a name and read/write JSON by key/value.

[Joel Denke]

I want one ORM/database tool and one simple data storage tool, not two database tools built on top of multiple database engines.
I will see if data store fits my case, hopefully 🙂

[Jeff Lockhart]

I've commonly used SQLite beneath an ORM in the past, with SharedPreferences or NSUserDefaults for simpler key/value persistence. So I understand the common methodology and why you'd prefer that route.

Personally, I prefer one database engine that can handle simple or complex data storage well. I've found a data structure or persistence use case can evolve such that the originally chosen persistence technology falls short of future needs. And I also like that Couchbase Lite really handles both use cases well out of the box, without the need for separate solutions.

Often relational databases don't work well for key/value scenarios because the data is flat. But Couchbase Lite is a JSON document model, allowing a flexible schema of arbitrary depth.

I've also found ORMs often outgrow their usefulness at some point too, where certain queries simply aren't possible without bypassing the layer, which is why SQLDelight has chosen to forego this abstraction. Couchbase Lite (and Kotbase) are similar in this regard.

The built-in offline-first cloud-to-edge data sync is the sugar on top for me, as this is such a common challenge. It's great to have a robust solution out of the box.

[Jeff Lockhart]

Definitely update this thread if you find datastore doesn't persist its data between app updates. This would be very strange indeed.