BatchOperations: create_primary_key and create_check_constraint

[sqlalchemy-bot]

Migrated issue, originally created by Felix Zumstein (@fzumstein)

Is there a special reason these two methods are "not yet implemented"? Or are they planned?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

probably only because they havent been tested. Can you try out this patch and let me know if it works rudimentally? I dont think special logic should be needed for check constraints. For the PK constraint, the Table object has to replace its already present PKC which I think it should do, so that "should" work also:

diff --git a/alembic/operations.py b/alembic/operations.py
index 2bf8060..46bc8c6 100644
--- a/alembic/operations.py
+++ b/alembic/operations.py
@@ -1356,7 +1356,7 @@ class BatchOperations(Operations):
         return super(BatchOperations, self).drop_column(
             self.impl.table_name, column_name, schema=self.impl.schema)
 
-    def create_primary_key(self, name, cols):
+    def create_primary_key(self, name, cols, **kw):
         """Issue a "create primary key" instruction using the
         current batch migration context.
 
@@ -1368,7 +1368,9 @@ class BatchOperations(Operations):
             :meth:`.Operations.create_primary_key`
 
         """
-        raise NotImplementedError("not yet implemented")
+        kw['schema'] = self.impl.schema
+        return super(BatchOperations, self).create_primary_key(
+            name, self.impl.table_name, cols, **kw)
 
     def create_foreign_key(
             self, name, referent, local_cols, remote_cols, **kw):
@@ -1422,7 +1424,9 @@ class BatchOperations(Operations):
             :meth:`.Operations.create_check_constraint`
 
         """
-        raise NotImplementedError("not yet implemented")
+        kw['schema'] = self.impl.schema
+        return super(BatchOperations, self).create_check_constraint(
+            name, self.impl.table_name, condition, **kw)
 
     def drop_constraint(self, name, type_=None):
         """Issue a "drop constraint" instruction using the

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• added labels: batch migrations

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• set milestone to "tier 1"

[sqlalchemy-bot]

Felix Zumstein (@fzumstein) wrote:

Hey thanks for the quick reply! The check constraint works, but the PK constraint ignores the name, i.e. it works but it creates an unnamed PK.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

• Implemented support for :meth:.BatchOperations.create_primary_key
  and :meth:.BatchOperations.create_check_constraint.
  fixes BatchOperations: create_primary_key and create_check_constraint #305
• table keyword arguments are copied from the original reflected table,
  such as the "mysql_engine" keyword argument.

→ 849996a

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

• Implemented support for :meth:.BatchOperations.create_primary_key
  and :meth:.BatchOperations.create_check_constraint.
  fixes BatchOperations: create_primary_key and create_check_constraint #305
• table keyword arguments are copied from the original reflected table,
  such as the "mysql_engine" keyword argument.

→ a294f8c

[sqlalchemy-bot]

Changes by Michael Bayer (@zzzeek):

• changed status to closed

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

primary key names are a little tricky as we don't support reflecting those names on most backends, but the batch mechanism will write it out if it has it. This is in master + a backport to 0.7.7 though at the moment it's not clear if 0.7.7 will just become 0.8.0.