New operation: create_constraint

[kvch]

This PR adds a new operation named create_constraint. Previously, we only supported adding constraints to columns. This operation lets us define table level constraints including multiple columns.

The operation supports foreign_key, check and unique constraint definition on tables.

Examples

Foreign key

{
  "name": "44_add_foreign_key_table_reference_constraint",
  "operations": [
    {
      "create_constraint": {
        "type": "foreign_key",
        "table": "tickets",
        "name": "fk_sellers",
        "columns": [
          "sellers_name",
          "sellers_zip"
        ],
        "references": {
          "table": "sellers",
          "columns": [
            "name",
            "zip"
          ],
          "on_delete": "CASCADE"
        }
      }
    }
  ]
}

Check

{
  "name": "45_add_table_check_constraint",
  "operations": [
    {
      "create_constraint": {
        "type": "check",
        "table": "tickets",
        "name": "check_zip_name",
        "check": "sellers_name IS NOT NULL AND sellers_zip < 1000",
        "up": "(SELECT 'noname', 999)",
        "down": "(SELECT sellers_name, sellers_zip FROM tickets WHERE sellers_name IS NOT NULL AND sellers_zip < 1000)"
      }
    }
  ]
}

Unique

{
  "name": "46_add_table_unique_constraint",
  "operations": [
    {
      "create_constraint": {
        "type": "unique",
        "table": "tickets",
        "name": "unique_zip_name",
        "columns": ["sellers_name", "sellers_zip"]
      }
    }
  ]
}

Related

Requires #413
Requires #426
Closes #81

[JoachimKoenigslieb]

This seems super useful. Right now there is no other ways to add a UNIQUE constraint on a table that applies across columns right?

[ryanslade]

Drive by comment, I didn't do a full review, but the drop_constraint operation fails currently if the constraint was created against more than one column. Not sure if we want to change that here.

[kvch]

@JoachimKoenigslieb You can create a unique index on a table using create_index operation and specify a list of columns. When you add unique constraint to a column or groups of columns, PostgreSQL creates a unique index for it. So the outcome of both operation is the same, you can make sure that the values in those columns are unique.

[kvch]

@ryanslade If you are ok with reviewing a big PR, I am happy to add it. But to ease the burden on the reviewer, it would be better to address drop_constraint problems as a follow-up. Your choice.

[ryanslade]

@ryanslade If you are ok with reviewing a big PR, I am happy to add it. But to easy the burden on the reviewer, it would be better to address drop_constraint problems as a follow-up. Your choice.

Happy for it to be in another PR, just wanted to make sure you were aware of the limitation.

[kvch]

Created a follow up issue to track drop_constraint changes: #458

[andrew-farries]

Left some comments.

Could this PR be split into three pieces? One each for CHECK, UNIQUE and FOREiGN KEY constraints. It think that's going to make the implementation and review easier.

I've only looked at the table levelCHECK constraints in detail so far. The implementation there adds the new constraint to the affected columns directly. In the case of single-column CHECK constraints added via the alter_column operation, the affected column is duplicated and backfilled and the constraint added to the new column. This gives us a 'zero downtime, multiversion' migration as the old column without the constraint is referenced by the old versioned view and the new column with the constraint is referenced from the new versioned view.

By adding the CHECK constraint directly to the columns, we break this as now both old and new versions of the schema will be affected by the constraint.

We will need to do the same thing for these potentially multi-column CHECK constraints as we do for the single column versions:

• on Start : duplicate and backfill the affected columns and apply the constraint to the new columns.
• on Complete: validate the check constraint
• on Rollback: remove the duplicated columns

[kvch]

Turning it into draft and opening follow-up PRs.

[kvch]

Closing as the last PR has been opened: #471