Skip to content

Add support for alter_table set NOT NULL operations with rename_table operations #606

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

Merged
merged 6 commits into from
Jan 20, 2025

Conversation

andrew-farries
Copy link
Collaborator

@andrew-farries andrew-farries commented Jan 17, 2025

Ensure that multi-operation migrations combining alter_column SET NOT NULL and rename_table operations work as expected.

{
  "name": "06_multi_operation",
  "operations": [
    {
      "rename_table": {
        "from": "items",
        "to": "products"
      }
    },
    {
      "alter_column": {
        "table": "products",
        "column": "name",
        "nullable": false,
        "up": "SELECT CASE WHEN name IS NULL THEN 'anonymous' ELSE name END",
        "down": "name || '_from_down_trigger'"
      }
    }
  ]
}

This migration renames a table and then sets a column's nullability on the renamed table.

Previously the migration would fail as the alter_column operation was unaware of the changes made by the preceding operation.

Part of #239

Ensure that a column on a table that has been renamed by a rename table
operation in the same migration can be set to `NOT NULL`.
Use the physical table name instead of the logical table name when
adding the `NOT NULL` constraint.
Use the physical table name when creating triggers rather than the
logical table name.

This means the operation `Start` will work if the table has been renamed
by a previous operation; in this case the logical table name will be
different from the physical table name.
Use the physical table name instead of the logical table name in the
`OpAlterColumn.Rollback` method.

This ensures the operation rolls back correctly if the table has been
renamed by a preceding operation in the same migration.
Add the table to the in-memory schema representation in the
`OpCreateTable.Complete` method.

This ensures the table is available to subsequent `Complete`s of
operations in the same migration.
Rename the table in the virtual schema so that the `Complete` methods
of subsequent operations in the same migration can find it.

Also update the physical name of the table in the virtual schema now
that it has really been renamed.
@andrew-farries andrew-farries merged commit db8123b into main Jan 20, 2025
28 checks passed
@andrew-farries andrew-farries deleted the support-rename-table-set-not-null branch January 20, 2025 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants