In an experiment run, check db, don't upgrade db #695
Assignees
Labels
Comments
|
We also discussed whether the check should either:
(or what-have-you). (1) might be nice, but assumes that processes are launched via an interactive terminal, (which is likely often not the case). Hence (2) might be safer and more appropriate, to just ensure that the error is reported/logged appropriately and with sufficient remediation advice. |
|
|
thcrock
added a commit
that referenced
this issue
May 15, 2019
To avoid the problem of time-consuming database upgrades happening when we don't want them, the Experiment now: 1. Checks to see if the results_schema_versions table exists at all. if it doesn't exist, upgrade. This is because means the results schema should be clean in this case, and new users won't have to always run a new thing when they first try Triage. 2. If it does exist, and the version number doesn't match what the code's current HEAD revision is, throw an error. The error message is customized to whether the database revision is a known revision to the code (easy case, just upgrade if you have time) or not (you probably upgraded on a different branch and need to go check out that branch to downgrade).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you install a new version of triage and try to run an experiment, the current behavior is to upgrade the database at that time. For databases with a large number of models and predictions, this can launch an extremely time-consuming (and potentially undesirable) process without warning the user.
Instead, check the db version and raise an error if it is incorrect, with a helpful error message warning users that upgrading (especially the predictions) can be time-consuming.
The text was updated successfully, but these errors were encountered: