Including CHECK constraints

包括 CHECK 约束

As of Alembic 1.7, named CHECK constraints are automatically included in batch mode, as modern SQLAlchemy versions are capable of reflecting these constraints like any other constraint.

从 Alembic 1.7 开始，已命名 的 CHECK 约束自动包含在批处理模式中，因为现代 SQLAlchemy 版本能够像任何其他约束一样反映这些约束。

Note that when dropping or renaming a column that is mentioned in a named CHECK constraint, this CHECK constraint must be explicitly dropped first, as Alembic has no means of linking a reflected CHECK constraint to that column. Supposing column q of some_table were mentioned in a CHECK constraint named ck1. In order to drop this column, we have to drop the check constraint also:

请注意，当删除或重命名命名 CHECK 约束中提到的列时，必须首先显式删除此 CHECK 约束，因为 Alembic 无法将反射的 CHECK 约束链接到该列。 假设 some_table 的列 q 在名为 ck1 的 CHECK 约束中被提及。 为了删除此列，我们还必须删除检查约束：

with self.op.batch_alter_table("some_table") as batch_op:
    batch_op.drop_constraint("ck1", "check")
    batch_op.drop_column('q')

Changed in version 1.7: Named CHECK constraints participate in batch mode in the same way as any other kind of constraint. This requires that column drops or renames now include explicit directives to drop an existing named constraint which refers to this column, as it will otherwise not be automatically detected as being associated with that particular column.

Unnamed CHECK constraints continue to be silently omitted from the table recreate operation.

版本1.7更新: 命名 CHECK 约束以与任何其他类型的约束相同的方式参与批处理模式。 这要求列的删除或重命名现在包含显式指令, 以删除引用此列的现有命名约束，否则将不会自动检测到它与该特定列的关联关系。

未命名的 CHECK 约束将继续在表重新创建操作中被忽略。

For unnamed CHECK constraints, these are still not automatically included as part of the batch process. Note that this limitation includes the CHECK constraints generated by the Boolean or Enum datatypes, which up through SQLAlchemy 1.3 would generate CHECK constraints automatically and cannot be tracked to the reflected table, assuming they are generated in an unnamed way.

对于 未命名 的 CHECK 约束，它们仍然不会自动包含在批处理过程中。 请注意，此限制包括由 Boolean 或 Enum 数据类型生成的 CHECK 约束，通过 SQLAlchemy 1.3 将自动生成 CHECK 约束并且不能跟踪到反射表，假设它们以未命名的方式生成。

Unnamed constraints can be stated explicitly if they are to be included in the recreated table:

如果要在重新创建的表中包含未命名的约束，则可以显式声明它们：

with op.batch_alter_table("some_table", table_args=[
      CheckConstraint('x > 5')
  ]) as batch_op:
    batch_op.add_column(Column('foo', Integer))
    batch_op.drop_column('bar')

The above step needs only be taken for CHECK constraints that are explicitly stated as part of the table definition.

上述步骤只需要对明确声明为表定义的一部分的 CHECK 约束进行。

For CHECK constraints that are generated by datatypes such as Boolean or Enum, the type objects themselves must be named in order for their CHECK constraints to be included in the batch process. Boolean and Enum datatypes that do not have the .name attribute set will not have CHECK constraints regenerated. This name can be set by specifying the .name parameter or by using a named Python Enum object as the source of enumeration.

对于由 Boolean 或 Enum 等数据类型生成的 CHECK 约束，必须为类型对象本身命名，以便将它们的 CHECK 约束包含在批处理过程中。 没有设置 .name 属性的 Boolean 和 Enum 数据类型将不会重新生成 CHECK 约束。 可以通过指定 .name 参数或使用命名的 Python Enum 对象作为枚举源来设置此名称。