You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should consider specifying upgrade=true in the Run SpineOpt plugin tool and/or make true the default value for the keyword argument
The migration script should always automatically make a backup of the user's DB (I believe this is standard practice).
Context
Recently I ran a simple test model to test a new installation of toolbox/SpineOpt. It failed - see the traceback below. The reason was that some of the new parameters associated with the new unit_flow_capacity constraint forumulation, introduced in recent updates, were not present. It took a little while to figure out as the traceback isn't very helpful, especially for a new user.
The solution was to call run_spineopt() with the keyword argument upgrade = true or re-import the latest template.
The point of this is to highlight - that this might be a little troublesome for a new user or someone that isn't familliar with writing code. I think the main problem is that the Run SpineOpt plugin tool does not specify upgrade = true and the default value for this keyword argument is false. So all users with older DBs will encounter this show-stopping traceback unless they write some code.
When an old DB is run with upgrade = true the migration happens very gracefully.
Another aspect of the migration that we should consider is automatically backing up the old DB especially if we were to consider making upgrade = true the default, or at least specifying it in the Run SpineOpt plugin (and in the documentation/tutorials). There are a few reasons for this:
A user may wish to keep compatability with an older version of SpineOpt (e.g. perhaps they are running things on different machines that aren't all syncronised for some reason)
We might mess up with the migration script and/or there may be corner cases we didn't cover, so we don't want to irrecoverably corrupt a user's data
This discussion was converted from issue #837 on January 26, 2024 13:21.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello all,
TL/DR
upgrade=true
in the Run SpineOpt plugin tool and/or maketrue
the default value for the keyword argumentContext
Recently I ran a simple test model to test a new installation of toolbox/SpineOpt. It failed - see the traceback below. The reason was that some of the new parameters associated with the new
unit_flow_capacity
constraint forumulation, introduced in recent updates, were not present. It took a little while to figure out as the traceback isn't very helpful, especially for a new user.The solution was to call run_spineopt() with the keyword argument
upgrade = true
or re-import the latest template.The point of this is to highlight - that this might be a little troublesome for a new user or someone that isn't familliar with writing code. I think the main problem is that the Run SpineOpt plugin tool does not specify
upgrade = true
and the default value for this keyword argument is false. So all users with older DBs will encounter this show-stopping traceback unless they write some code.When an old DB is run with
upgrade = true
the migration happens very gracefully.Another aspect of the migration that we should consider is automatically backing up the old DB especially if we were to consider making
upgrade = true
the default, or at least specifying it in the Run SpineOpt plugin (and in the documentation/tutorials). There are a few reasons for this:Beta Was this translation helpful? Give feedback.
All reactions