feat!: drop LegacyVariableName from coder parameter #8360
Conversation
| @@ -0,0 +1 @@ | |||
| ALTER TABLE template_version_parameters DROP COLUMN legacy_variable_name; | |||
There was a problem hiding this comment.
What could happen if legacy variables are still present when we upgrade? Should we somehow prevent this migration if any column has a non-empty value here?
I'm not sure what we should do, but perhaps something like this (granted the condition is needed).
DO $$
BEGIN
RAISE 'Bad things will happen!';
END;
$$ LANGUAGE plpgsql;There was a problem hiding this comment.
Legacy variable names are not used since 2 minor releases (v0.24.0, v0.25.0). I would assume that we can just drop the column :) Users who forgot to migrate workspaces will not benefit from the legacy_variable_name property.
| @@ -27,6 +27,8 @@ message RichParameterOption { | |||
|
|
|||
| // RichParameter represents a variable that is exposed. | |||
| message RichParameter { | |||
| reserved 14; | |||
There was a problem hiding this comment.
Should we reserve the name as well? I doubt it will be a problem, but I'm overly cautious 😄.
There was a problem hiding this comment.
Oh yeah, that's a safer approach 👍
This PR catches up with changes introduced to terraform-provider-coder.
It looks big and scary, but in reality, it removes
legacy_variable_namefrom API/database/proto, which was used only for migration purposes (not anymore).