-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Make catalog metadata migrations work on all schema versions (fix #2826) #2379
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.
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
Conversation
|
Beep boop! 🤖 Hey @ajeetdsouza, thanks for your PR! One of my human friends will review this PR and get back to you as soon as possible. 🕐 Stay awesome! 😎 |
|
Deploy preview for hasura-docs ready! Built with commit b9bfb06 |
|
Review app for commit 368b476 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit 76bdfe6 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit 7ba1b7c deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit 2c60cc7 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit c10ace0 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
@ajeetdsouza Can you update the description to indicate that this PR is talking about catalog migrations that happen when Hasura versions are upgraded and not the "CLI migrations" -- which the users are familiar with? |
|
Review app for commit fe7b6d2 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit 6cda36a deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit 5650bcc deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit fe8fce2 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app for commit b9bfb06 deployed to Heroku: https://hge-ci-pull-2379.herokuapp.com |
|
Review app https://hge-ci-pull-2379.herokuapp.com is deleted |
|
Beep boop! 🤖 Awesome work @ajeetdsouza! All of us at Hasura ❤️ what you did. Thanks again 🤗 |
…ura#2826) (hasura#2379) * Separate DB and metadata migrations * Refactor Migrate.hs to generate list of migrations at compile-time * Replace ginger with shakespeare to improve performance * Improve migration log messages
Description
As reported in #2826, catalog metadata migrations can fail when migrating from older catalog versions. This happens because catalog metadata is updated by running ordinary RQL queries like
add_existing_table_or_viewandcreate_object_relationship, but the implementations of those APIs will always use the newest version of the code, which may depend on recent schema changes.This change fixes that by running all database migrations before changing the metadata at all, then simply dropping all metadata for the entire Hasura catalog and recreating it from scratch.
Affected components
Related Issues
#2826
Solution and Design
Changes to catalog metadata are no longer expressed as individual migrations. Instead, the
src-rsr/hdb_metadata.yamlfile is used directly to recreate all catalog metadata in one step.src-exec/Migrate.hshas been rewritten to both incorporate this behavioral change and to avoid so much duplication: all SQL migrations are now stored in separate files (now in thesrc-rsr/migrations/directory), andMigrate.hsautomatically loads the necessary migration scripts without needing to maintain an explicit list.A few other changes have been made to support the main goal of this PR:
The catalog version is now defined in a new
Migrate.Versionmodule instead of directly inMigrate. This is unfortunately necessary to workaround the GHC stage restriction, which forbids using a definition from the current module in a Template Haskell splice.A new
HasSystemDefinedtypeclass has been introduced to parameterize metadata-altering queries over whether or not the current metadata objects being defined should be considered “system-defined” or not. This avoids needing to explicitly specifysystem_defined: truefor every query inhdb_metadata.yaml.The use of the
gingerlibrary for templating has been removed and replaced withshakespeare. Profiling revealed thatgingeris remarkably slow, which caused problems due to the higher frequency at which the new approach to migrations callsbuildSchemaCache. Since the templates are all statically known at compile-time,shakespeareis dramatically more efficient: it uses Template Haskell to compile the templates to Haskell code that simply uses variables from the current lexical scope.Steps to test and verify
Fire up an older version of
graphql-engineusing Docker, and test if migrations are working by switching to this version.Limitations, known bugs & workarounds
None