Implement adding uniqueness constraints to columns

[andrew-farries]

Add support for adding uniqueness constraints to columns. Such a migration looks like this:

{
  "name": "15_set_columns_unique",
  "operations": [
    {
      "set_unique": {
        "name": "reviews_username_product_unique",
        "table": "reviews",
        "columns": [
          "username",
          "product"
        ]
      }
    }
  ]
}

This migration adds a unique constraint spanning the username and product columns in the reviews table.

• On Start a unique index is created concurrently.
• On Rollback the unique index is removed.
• On Complete a unique constraint is added to the column using the index.

Creating a unique constraint directly requires a full table exclusive lock. By first creating a unique index concurrently and then adding a constraint using the index the need for the lock is avoided.

[exekias]

I've one question here, when will the constraint start being enforced? If I understand correctly, it would only be after the call to complete. Ideally, we offer the guarantee that each version of the schema fully respects it. Meaning that accessing through the new version enforces the unique constraint while accessing the old one doesn't.

If I'm not mistaken, it almost feels like we need to create a new column and copy all the data (optionally applying an up function), then enforce the constraint in the new column, but not in the old one. Does this make sense?

[exekias]

Another though, I go back and forth with doing this as its own op or having it as part of the alter column operation. I start to see that alter column may be better, but we can decide on this later.

[andrew-farries]

I've one question here, when will the constraint start being enforced? If I understand correctly, it would only be after the call to complete. Ideally, we offer the guarantee that each version of the schema fully respects it. Meaning that accessing through the new version enforces the unique constraint while accessing the old one doesn't.

Uniqueness is enforced after start, when the UNIQUE index is created:

https://github.com/xataio/pg-roll/blob/5d64ac47d65b6a365d0372d210674d2d6e98fcb8/pkg/migrations/op_set_unique.go#L23-L28

We have a test that ensures that inserts to both the old and new schema that violate the constraint will fail:

https://github.com/xataio/pg-roll/blob/5d64ac47d65b6a365d0372d210674d2d6e98fcb8/pkg/migrations/op_set_unique_test.go#L58-L75

The only thing that Complete does is convert the index into a constraint using the unique index. We don't create the constraint directly on Start to avoid taking an exclusive lock on the table.

[andrew-farries]

Another though, I go back and forth with doing this as its own op or having it as part of the alter column operation. I start to see that alter column may be better, but we can decide on this later.

Yes, I was thinking similarly. A single 'alter table' operation might be the best approach.

[exekias]

We talked about this offline, and the outcome was:

• We will keep separate operations, and probably merge them later in a single alter column migration
• This operation is ok as it is. We are breaking the promise of keeping the same constraints in the old schema (as null will be enforced after start), but:
  • We have ideas to improve this in the future if we find the need, like for instance allowing the user to define an up migration that works as a fallback for non-unique values
  • Since the migration will fail to start if there are repeated values, it may be fine for the clients to get the constraint enforced later