Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Janus should refuse to start up if it sees an unsupported schema version #1241

Closed
tgeoghegan opened this issue Apr 12, 2023 · 2 comments · Fixed by #1272
Closed

Janus should refuse to start up if it sees an unsupported schema version #1241

tgeoghegan opened this issue Apr 12, 2023 · 2 comments · Fixed by #1272
Assignees
@tgeoghegan

Comments

@tgeoghegan
Copy link
Contributor

As of #1218, we now have versioned SQL schema migration scripts. Deploying a migration from schema n to n+1 will involve deploying a Janus that can support both schema versions and then applying the migration to schema n+1. To make this safer, any Janus version should have a list or range of supported schema versions compiled into it so that at startup, it can query the _sqlx_migrations table to see what the current version is and refuse to startup if it doesn't recognize it. This reduces the risk of Janus corrupting data.
@tgeoghegan tgeoghegan self-assigned this Apr 12, 2023
@tgeoghegan
Copy link
Contributor Author

Brandon's comment in #1219 is relevant

One higher-level concern I didn't notice addressed in any of the existing issues/PRs: how will we determine which schema version(s) are expected to work with a given Janus version?

Even something as simple as "the latest committed schema version is the only version that works with a given Janus version" will probably work out fine, but we should document this.

We've discussed a little the ordering of the schema updates against Janus version updates, but this should be documented as well. Is the expectation that if a given release updates both the schema & Janus, the schema update is generally applied first?

(these two questions are related, in the sense that both are reaching for a documented mapping of "schema versions that are expected to work with a given Janus version")

This was referenced Apr 12, 2023
Merged
Merged
tgeoghegan added a commit that referenced this issue Apr 18, 2023
@tgeoghegan
Check DB schema version at startup
b2e096a 
Creating a `Datastore` now checks the version of the most recently
applied migration script against an array of supported versions compiled
into Janus. If the current schema is not supported, `Datastore::new`
returns an error.

Resolves #1241
@tgeoghegan tgeoghegan mentioned this issue Apr 18, 2023
Merged
tgeoghegan added a commit that referenced this issue Apr 18, 2023
@tgeoghegan
Check DB schema version at startup
1e1a9fa 
Creating a `Datastore` now checks the version of the most recently
applied migration script against an array of supported versions compiled
into Janus. If the current schema is not supported, `Datastore::new`
returns an error.

Resolves #1241
tgeoghegan added a commit that referenced this issue Apr 24, 2023
@tgeoghegan
Check DB schema version at startup
9c1457a 
Creating a `Datastore` now checks the version of the most recently
applied migration script against an array of supported versions compiled
into Janus. If the current schema is not supported, `Datastore::new`
returns an error. Also adds a configuration option to disable this new
feature. This is needed because the Janus interop binaries apply schema
migrations at startup, after being handed control by `janus_main`.

Resolves #1241
tgeoghegan added a commit that referenced this issue Apr 24, 2023
@tgeoghegan
Check DB schema version at startup (#1272)
efbc6ee 
Creating a `Datastore` now checks the version of the most recently
applied migration script against an array of supported versions compiled
into Janus. If the current schema is not supported, `Datastore::new`
returns an error. Also adds a configuration option to disable this new
feature. This is needed because the Janus interop binaries apply schema
migrations at startup, after being handed control by `janus_main`.

Resolves #1241
@tgeoghegan
Copy link
Contributor Author

For posterity: #1277 was a part of this issue, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tgeoghegan tgeoghegan

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Check DB schema version at startup divviup/janus
1 participant
@tgeoghegan