Skip to content

Compatible versioning and migrations #80

@ryanheise

Description

@ryanheise

On Android, sqlite3 databases use the user_version pragma to store the version, with 0 (the default) indicating the database is new and the schema needs to be created. Schema upgrade and downgrade functions are contained in the app binary (containing static SQL statements), and there is no migrations table. To downgrade, the required SQL statements are in the app binary just like the upgrade SQL statements. So the only artifact stored in the database file itself that reflects versioning is the user_version pragma which is a standard feature of sqlite3.

sqflite also adopts the same practice.

I think this approach therefore has some desirable properties in terms of compatibility.

Do you have any thoughts/opinions on using this approach too, for compatibility? I realise that's complicated by the fact that you are already doing things a little differently from this and so any changes to this might introduce backwards compatibility issues for your own users, unless you can do this in a backwards compatible way.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions