-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Fixed width dashboard migration #38247
Conversation
3 migrations: - 1st adding the width column with default value of 'fixed' - 2nd updating all existing dashboards to have width 'full', which corresponds to what the current behaviour is (will be the 'old' behaviour after the fixed-width project lands). - The rolloback here is necessary but we don't care what happens as the column will be dropped immediately in the next rollback anyway - 3rd sets the notNullableConstraint. DefaultNull is 'full' here, just in case there's an existing dashboard whose width value is not yet set from the 1st migration. Don't know how that could happen, but its here in case
update-dashboard function now is aware of the :width key so those changes can end up in the transaction. Also added a width test that asserts that the value's default is "fixed", it can be changed, eg. to "full", but cannot be changed to other values.
ab31924
to
78960bf
Compare
:width key is now needed in some revision tests. As well we need a string communicating that the :width setting has changed from 'full' to 'fixed' or vice-versa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update the comment and remarks in the last migration and then it will be g2g.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
…metabase/metabase into fixed-width-dashboard-migration
Signed-off-by: Adam James <adam.vermeer2@gmail.com>
@adam-james-v Did you forget to add a milestone to the issue for this PR? When and where should I add a milestone? |
* Migration adding 'width' to Dashboards 3 migrations: - 1st adding the width column with default value of 'fixed' - 2nd updating all existing dashboards to have width 'full', which corresponds to what the current behaviour is (will be the 'old' behaviour after the fixed-width project lands). - The rolloback here is necessary but we don't care what happens as the column will be dropped immediately in the next rollback anyway - 3rd sets the notNullableConstraint. DefaultNull is 'full' here, just in case there's an existing dashboard whose width value is not yet set from the 1st migration. Don't know how that could happen, but its here in case * Dashboard PUT api endpoint accepts width changes and updates appdb update-dashboard function now is aware of the :width key so those changes can end up in the transaction. Also added a width test that asserts that the value's default is "fixed", it can be changed, eg. to "full", but cannot be changed to other values. * Add width to revision tests * Fix dashboard revision tests. :width key is now needed in some revision tests. As well we need a string communicating that the :width setting has changed from 'full' to 'fixed' or vice-versa. * Fix comments/remarks in migration to be accurate * Attempt to fix default not working mysql/mariadb * Set default in dashboard model Signed-off-by: Adam James <adam.vermeer2@gmail.com> * Revert default :width 'fixed' value. * Explicitly add default value 'fixed' for MySQL/MariaDB --------- Signed-off-by: Adam James <adam.vermeer2@gmail.com>
This PR addressed the first 2 items in #36358
The need was:
3 migrations were used to achieve this:
A test was added to the Dashboard api test namespace to make sure these properties are met after the migration.
I've also manually tested in the REPL:
The setting is exposed to change via
PUT /api/dashboard/:id
.