aerie-ui
aerie-ui copied to clipboard
NASA-AMMOS
View Definition Auto Migration
Auto migrate old UI view definitions. Closes #1490
Merge only after #1396 is merged.
Changes:
- Adds "version" as a property of the view definition
- Auto migrates old views from upload or when loading from db
- Notifies users if a view
Testing:
- Load a plan with no view specified in the url. The plan should load the default view.
- Verify that you can load a view made on the current branch. Try making a complex view with activity layer customizations since these are affected by the v0 -> v1 migration.
- Upload a view made prior to this branch and verify that it loads correctly (no success toast will appear since no additional db changes are needed besides nominal insert of the view during upload)
- Insert a view made prior to this branch using hasura playground. Load this view from a plan using the browse modal and verify that the view loads and a toast message alerts you that the view has been updated. Refresh the page and verify that no toast appears, indicating that the view was in fact updated in the db.
- Force a failure in the migration code (look at the 0 -> 1 migration function) and repeat step 4 and verify that an error toast alerts you that the migration of the view failed and that the default view is loaded. In this case there will only be a single row for the default view.
- Insert a view made prior to this branch using hasura playground. Load this view from a plan by specifying the view id in the URL. No toast will appear since migration is being performed on the server side during initial SSR.
- Force a failure in the migration code and repeat step 6 and verify that an error toast alerts you that the migration of the view failed and that the default view is loaded. In this case there will be a number of rows since our initial page load default view fetches various activity and resource types and attempts to display them.
- Test migration with a default mission model view
TODO:
- [x] Figure out what to do when view can't be migrated when loading from url, view browser, and imported views. May want to handle them differently? Right now they fall back to default view generation.
- [x] Figure out if we need to migrate the model default views?
- [x] Add and fix view tests
Tested thoroughly with @AaronPlave today and everything is looking good. Two small TODOs:
- If the migration code throws an error while uploading a view, it's not correctly reported in the UI & looks like a schema validation error instead. Can simulate this case by throwing an error in
migrateViewDefinitionV0toV1 - @AaronPlave will go through changes to the view schema since 2.11 release (May 2024) or earlier, and handle any additional changes in the migration to support views as far back as possible
We'd like to get a code review from @duranb next week but 👍 otherwise
Tested thoroughly with @AaronPlave today and everything is looking good. Two small TODOs:
- If the migration code throws an error while uploading a view, it's not correctly reported in the UI & looks like a schema validation error instead. Can simulate this case by throwing an error in
migrateViewDefinitionV0toV1- @AaronPlave will go through changes to the view schema since 2.11 release (May 2024) or earlier, and handle any additional changes in the migration to support views as far back as possible
We'd like to get a code review from @duranb next week but 👍 otherwise
Fixed the first issue and went through a year of view schema updates and didn't see anything else that needed to be handled.