JezK

Edit File: batch.html

<!DOCTYPE html>

<title>Running “Batch” Migrations for SQLite and Other Databases &#8212; Alembic 1.8.1 documentation</title>
 <link rel="stylesheet" type="text/css" href="_static/pygments.css" />
 <link rel="stylesheet" type="text/css" href="_static/nature_override.css" />
 <link rel="stylesheet" type="text/css" href="_static/copybutton.css" />
 <link rel="stylesheet" type="text/css" href="_static/changelog.css" />
 <link rel="stylesheet" type="text/css" href="_static/sphinx_paramlinks.css" />
 <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
 <script src="_static/jquery.js"></script>
 <script src="_static/underscore.js"></script>
 <script src="_static/doctools.js"></script>
 <script src="_static/clipboard.min.js"></script>
 <script src="_static/copybutton.js"></script>
 <link rel="index" title="Index" href="genindex.html" />
 <link rel="search" title="Search" href="search.html" />
 <link rel="next" title="Working with Branches" href="branches.html" />
 <link rel="prev" title="The Importance of Naming Constraints" href="naming.html" /> 
 </head><body>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="genindex.html" title="General Index"
 accesskey="I">index</a></li>
 <li class="right" >
 <a href="py-modindex.html" title="Python Module Index"
 >modules</a> |</li>
 <li class="right" >
 <a href="branches.html" title="Working with Branches"
 accesskey="N">next</a> |</li>
 <li class="right" >
 <a href="naming.html" title="The Importance of Naming Constraints"
 accesskey="P">previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="index.html">Alembic 1.8.1 documentation</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">Running “Batch” Migrations for SQLite and Other Databases</a></li> 
 </ul>
 </div>

<div class="document">
 <div class="documentwrapper">
 <div class="bodywrapper">
 <div class="body" role="main">
 
 <section id="running-batch-migrations-for-sqlite-and-other-databases">
<h1>Running “Batch” Migrations for SQLite and Other Databases<a class="headerlink" href="#running-batch-migrations-for-sqlite-and-other-databases" title="Permalink to this headline">¶</a></h1>
The SQLite database presents a challenge to migration tools
in that it has almost no support for the ALTER statement which
relational schema migrations rely upon. The rationale for this stems from
philosophical and architectural concerns within SQLite, and they are unlikely
to be changed.
Migration tools are instead expected to produce copies of SQLite tables that
correspond to the new structure, transfer the data from the existing
table to the new one, then drop the old table. For our purposes here
we’ll call this “move and copy” workflow, and in order to accommodate it
in a way that is reasonably predictable, while also remaining compatible
with other databases, Alembic provides the batch operations context.
Within this context, a relational table is named, and then a series of
mutation operations to that table alone are specified within
the block. When the context is complete, a process begins whereby the
“move and copy” procedure begins; the existing table structure is reflected
from the database, a new version of this table is created with the given
changes, data is copied from the
old table to the new table using “INSERT from SELECT”, and finally the old
table is dropped and the new one renamed to the original name.
The <a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a> method provides the gateway to this
process:
<div class="highlight-default notranslate"><div class="highlight"><pre>with op.batch_alter_table(&quot;some_table&quot;) as batch_op:
 batch_op.add_column(Column(&#39;foo&#39;, Integer))
 batch_op.drop_column(&#39;bar&#39;)
</pre></div>
</div>
When the above directives are invoked within a migration script, on a
SQLite backend we would see SQL like:
<div class="highlight-sql notranslate"><div class="highlight"><pre>CREATE TABLE _alembic_batch_temp (
 id INTEGER NOT NULL,
 foo INTEGER,
 PRIMARY KEY (id)
);
INSERT INTO _alembic_batch_temp (id) SELECT some_table.id FROM some_table;
DROP TABLE some_table;
ALTER TABLE _alembic_batch_temp RENAME TO some_table;
</pre></div>
</div>
On other backends, we’d see the usual <code class="docutils literal notranslate">ALTER</code> statements done as though
there were no batch directive - the batch context by default only does
the “move and copy” process if SQLite is in use, and if there are
migration directives other than <a class="reference internal" href="ops.html#alembic.operations.Operations.add_column" title="alembic.operations.Operations.add_column"><code class="xref py py-meth docutils literal notranslate">Operations.add_column()</code></a> present,
which is the one kind of column-level ALTER statement that SQLite supports.
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a> can be configured
to run “move and copy” unconditionally in all cases, including on databases
other than SQLite; more on this is below.
<section id="controlling-table-reflection">
<h2>Controlling Table Reflection<a class="headerlink" href="#controlling-table-reflection" title="Permalink to this headline">¶</a></h2>
The <code class="xref py py-class docutils literal notranslate">Table</code> object that is reflected when
“move and copy” proceeds is performed using the standard <code class="docutils literal notranslate">autoload=True</code>
approach. This call can be affected using the
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.reflect_args" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">reflect_args</code></a> and
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.reflect_kwargs" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">reflect_kwargs</code></a> arguments.
For example, to override a <code class="xref py py-class docutils literal notranslate">Column</code> within
the reflection process such that a <code class="xref py py-class docutils literal notranslate">Boolean</code>
object is reflected with the <code class="docutils literal notranslate">create_constraint</code> flag set to <code class="docutils literal notranslate">False</code>:
<div class="highlight-default notranslate"><div class="highlight"><pre>with self.op.batch_alter_table(
 &quot;bar&quot;,
 reflect_args=[Column(&#39;flag&#39;, Boolean(create_constraint=False))]
) as batch_op:
 batch_op.alter_column(
 &#39;flag&#39;, new_column_name=&#39;bflag&#39;, existing_type=Boolean)
</pre></div>
</div>
Another use case, add a listener to the <code class="xref py py-class docutils literal notranslate">Table</code>
as it is reflected so that special logic can be applied to columns or
types, using the <code class="xref py py-meth docutils literal notranslate">column_reflect()</code> event:
<div class="highlight-default notranslate"><div class="highlight"><pre>def listen_for_reflect(inspector, table, column_info):
 &quot;correct an ENUM type&quot;
 if column_info[&#39;name&#39;] == &#39;my_enum&#39;:
 column_info[&#39;type&#39;] = Enum(&#39;a&#39;, &#39;b&#39;, &#39;c&#39;)

with self.op.batch_alter_table(
 &quot;bar&quot;,
 reflect_kwargs=dict(
 listeners=[
 (&#39;column_reflect&#39;, listen_for_reflect)
 ]
 )
) as batch_op:
 batch_op.alter_column(
 &#39;flag&#39;, new_column_name=&#39;bflag&#39;, existing_type=Boolean)
</pre></div>
</div>
The reflection process may also be bypassed entirely by sending a
pre-fabricated <code class="xref py py-class docutils literal notranslate">Table</code> object; see
<a class="reference internal" href="#batch-offline-mode">Working in Offline Mode</a> for an example.
</section>
<section id="dealing-with-constraints">
<h2>Dealing with Constraints<a class="headerlink" href="#dealing-with-constraints" title="Permalink to this headline">¶</a></h2>
There are a variety of issues when using “batch” mode with constraints,
such as FOREIGN KEY, CHECK and UNIQUE constraints. This section
will attempt to detail many of these scenarios.
<section id="dropping-unnamed-or-named-foreign-key-constraints">
<h3>Dropping Unnamed or Named Foreign Key Constraints<a class="headerlink" href="#dropping-unnamed-or-named-foreign-key-constraints" title="Permalink to this headline">¶</a></h3>
SQLite, unlike any other database, allows constraints to exist in the
database that have no identifying name. On all other backends, the
target database will always generate some kind of name, if one is not
given.
The first challenge this represents is that an unnamed constraint can’t
by itself be targeted by the <a class="reference internal" href="ops.html#alembic.operations.BatchOperations.drop_constraint" title="alembic.operations.BatchOperations.drop_constraint"><code class="xref py py-meth docutils literal notranslate">BatchOperations.drop_constraint()</code></a> method.
An unnamed FOREIGN KEY constraint is implicit whenever the
<code class="xref py py-class docutils literal notranslate">ForeignKey</code>
or <code class="xref py py-class docutils literal notranslate">ForeignKeyConstraint</code> objects are used without
passing them a name. Only on SQLite will these constraints remain entirely
unnamed when they are created on the target database; an automatically generated
name will be assigned in the case of all other database backends.
A second issue is that SQLAlchemy itself has inconsistent behavior in
dealing with SQLite constraints as far as names. Prior to version 1.0,
SQLAlchemy omits the name of foreign key constraints when reflecting them
against the SQLite backend. So even if the target application has gone through
the steps to apply names to the constraints as stated in the database,
they still aren’t targetable within the batch reflection process prior
to SQLAlchemy 1.0.
Within the scope of batch mode, this presents the issue that the
<a class="reference internal" href="ops.html#alembic.operations.BatchOperations.drop_constraint" title="alembic.operations.BatchOperations.drop_constraint"><code class="xref py py-meth docutils literal notranslate">BatchOperations.drop_constraint()</code></a> method requires a constraint name
in order to target the correct constraint.
In order to overcome this, the <a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a> method supports a
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.naming_convention" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">naming_convention</code></a> argument, so that
all reflected constraints, including foreign keys that are unnamed, or
were named but SQLAlchemy isn’t loading this name, may be given a name,
as described in <a class="reference internal" href="naming.html#autogen-naming-conventions">Integration of Naming Conventions into Operations, Autogenerate</a>. Usage is as follows:
<div class="highlight-default notranslate"><div class="highlight"><pre>naming_convention = {
 &quot;fk&quot;:
 &quot;fk_%(table_name)s_%(column_0_name)s_%(referred_table_name)s&quot;,
}
with self.op.batch_alter_table(
 &quot;bar&quot;, naming_convention=naming_convention) as batch_op:
 batch_op.drop_constraint(
 &quot;fk_bar_foo_id_foo&quot;, type_=&quot;foreignkey&quot;)
</pre></div>
</div>
Note that the naming convention feature requires at least
SQLAlchemy 0.9.4 for support.
</section>
<section id="including-unnamed-unique-constraints">
<h3>Including unnamed UNIQUE constraints<a class="headerlink" href="#including-unnamed-unique-constraints" title="Permalink to this headline">¶</a></h3>
A similar, but frustratingly slightly different, issue is that in the
case of UNIQUE constraints, we again have the issue that SQLite allows
unnamed UNIQUE constraints to exist on the database, however in this case,
SQLAlchemy prior to version 1.0 doesn’t reflect these constraints at all.
It does properly reflect named unique constraints with their names, however.
So in this case, the workaround for foreign key names is still not sufficient
prior to SQLAlchemy 1.0. If our table includes unnamed unique constraints,
and we’d like them to be re-created along with the table, we need to include
them directly, which can be via the
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.table_args" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">table_args</code></a> argument:
<div class="highlight-default notranslate"><div class="highlight"><pre>with self.op.batch_alter_table(
 &quot;bar&quot;, table_args=(UniqueConstraint(&#39;username&#39;),)
 ):
 batch_op.add_column(Column(&#39;foo&#39;, Integer))
</pre></div>
</div>
</section>
<section id="changing-the-type-of-boolean-enum-and-other-implicit-check-datatypes">
<h3>Changing the Type of Boolean, Enum and other implicit CHECK datatypes<a class="headerlink" href="#changing-the-type-of-boolean-enum-and-other-implicit-check-datatypes" title="Permalink to this headline">¶</a></h3>
The SQLAlchemy types <code class="xref py py-class docutils literal notranslate">Boolean</code> and
<code class="xref py py-class docutils literal notranslate">Enum</code> are part of a category of types known as
“schema” types; this style of type creates other structures along with the
type itself, most commonly (but not always) a CHECK constraint.
Alembic handles dropping and creating the CHECK constraints here automatically,
including in the case of batch mode. When changing the type of an existing
column, what’s necessary is that the existing type be specified fully:
<div class="highlight-default notranslate"><div class="highlight"><pre>with self.op.batch_alter_table(&quot;some_table&quot;) as batch_op:
 batch_op.alter_column(
 &#39;q&#39;, type_=Integer,
 existing_type=Boolean(create_constraint=True, constraint_name=&quot;ck1&quot;))
</pre></div>
</div>
When dropping a column that includes a named CHECK constraint, as of Alembic
1.7 this named constraint must also be provided using a similar form, as there
is no ability for Alembic to otherwise link this reflected CHECK constraint as
belonging to a particular column:
<div class="highlight-default notranslate"><div class="highlight"><pre>with self.op.batch_alter_table(&quot;some_table&quot;) as batch_op:
 batch_op.drop_column(
 &#39;q&#39;,
 existing_type=Boolean(create_constraint=True, constraint_name=&quot;ck1&quot;))
 )
</pre></div>
</div>
<div class="versionchanged">
Changed in version 1.7: The <a class="reference internal" href="ops.html#alembic.operations.BatchOperations.drop_column" title="alembic.operations.BatchOperations.drop_column"><code class="xref py py-meth docutils literal notranslate">BatchOperations.drop_column()</code></a> operation can
accept an <code class="docutils literal notranslate">existing_type</code> directive where a “schema type” such as
<code class="xref py py-class docutils literal notranslate">Boolean</code> and <code class="xref py py-class docutils literal notranslate">Enum</code> may
be specified such that an associated named constraint can be removed.
</div>
</section>
<section id="including-check-constraints">
<h3>Including CHECK constraints<a class="headerlink" href="#including-check-constraints" title="Permalink to this headline">¶</a></h3>
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.
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 <code class="docutils literal notranslate">q</code> of <code class="docutils literal notranslate">some_table</code> were mentioned in a CHECK
constraint named <code class="docutils literal notranslate">ck1</code>. In order to drop this column, we have to drop
the check constraint also:
<div class="highlight-default notranslate"><div class="highlight"><pre>with self.op.batch_alter_table(&quot;some_table&quot;) as batch_op:
 batch_op.drop_constraint(&quot;ck1&quot;, &quot;check&quot;)
 batch_op.drop_column(&#39;q&#39;)
</pre></div>
</div>
<div class="versionchanged">
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.
</div>
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
<code class="xref py py-class docutils literal notranslate">Boolean</code> or <code class="xref py py-class docutils literal notranslate">Enum</code>
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.
Unnamed constraints can be stated explicitly if they are to be included in the
recreated table:
<div class="highlight-default notranslate"><div class="highlight"><pre>with op.batch_alter_table(&quot;some_table&quot;, table_args=[
 CheckConstraint(&#39;x &gt; 5&#39;)
 ]) as batch_op:
 batch_op.add_column(Column(&#39;foo&#39;, Integer))
 batch_op.drop_column(&#39;bar&#39;)
</pre></div>
</div>
The above step needs only be taken for CHECK constraints that are explicitly stated
as part of the table definition.
For CHECK constraints that are generated by datatypes such as
<code class="xref py py-class docutils literal notranslate">Boolean</code> or <code class="xref py py-class docutils literal notranslate">Enum</code>, 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 <code class="docutils literal notranslate">.name</code> attribute set will not have CHECK constraints
regenerated. This name can be set by specifying the <code class="docutils literal notranslate">.name</code> parameter
or by using a named Python <code class="docutils literal notranslate">Enum</code> object as the source of enumeration.
</section>
<section id="dealing-with-referencing-foreign-keys">
<h3>Dealing with Referencing Foreign Keys<a class="headerlink" href="#dealing-with-referencing-foreign-keys" title="Permalink to this headline">¶</a></h3>
It is important to note that batch table operations do not work with
foreign keys that enforce referential integrity. This because the
target table is dropped; if foreign keys refer to it, this will raise
an error. On SQLite, whether or not foreign keys actually enforce is
controlled by the <code class="docutils literal notranslate">PRAGMA FOREIGN KEYS</code> pragma; this pragma, if in use,
must be disabled when the workflow mode proceeds. When the operation is
complete, the batch-migrated table will have the same name
that it started with, so those referring foreign keys will again
refer to this table.
A special case is dealing with self-referring foreign keys. Here,
Alembic takes a special step of recreating the self-referring foreign key
as referring to the original table name, rather than at the “temp” table,
so that like in the case of other foreign key constraints, when the table
is renamed to its original name, the foreign key
again references the correct table. This operation only works when
referential integrity is disabled, consistent with the same requirement
for referring foreign keys from other tables.
When SQLite’s <code class="docutils literal notranslate">PRAGMA FOREIGN KEYS</code> mode is turned on, it does provide
the service that foreign key constraints, including self-referential, will
automatically be modified to point to their table across table renames,
however this mode prevents the target table from being dropped as is required
by a batch migration. Therefore it may be necessary to manipulate the
<code class="docutils literal notranslate">PRAGMA FOREIGN KEYS</code> setting if a migration seeks to rename a table vs.
batch migrate it.
</section>
</section>
<section id="working-in-offline-mode">
<h2>Working in Offline Mode<a class="headerlink" href="#working-in-offline-mode" title="Permalink to this headline">¶</a></h2>
In the preceding sections, we’ve seen how much of an emphasis the
“move and copy” process has on using reflection in order to know the
structure of the table that is to be copied. This means that in the typical
case, “online” mode, where a live database connection is present so that
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a> can reflect the table from the
database, is required; the <code class="docutils literal notranslate">--sql</code> flag cannot be used without extra
steps.
To support offline mode, the system must work without table reflection
present, which means the full table as it intends to be created must be
passed to <a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a> using
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.copy_from" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">copy_from</code></a>:
<div class="highlight-default notranslate"><div class="highlight"><pre>meta = MetaData()
some_table = Table(
 &#39;some_table&#39;, meta,
 Column(&#39;id&#39;, Integer, primary_key=True),
 Column(&#39;bar&#39;, String(50))
)

with op.batch_alter_table(&quot;some_table&quot;, copy_from=some_table) as batch_op:
 batch_op.add_column(Column(&#39;foo&#39;, Integer))
 batch_op.drop_column(&#39;bar&#39;)
</pre></div>
</div>
The above use pattern is pretty tedious and quite far off from Alembic’s
preferred style of working; however, if one needs to do SQLite-compatible
“move and copy” migrations and need them to generate flat SQL files in
“offline” mode, there’s not much alternative.
</section>
<section id="batch-mode-with-autogenerate">
<h2>Batch mode with Autogenerate<a class="headerlink" href="#batch-mode-with-autogenerate" title="Permalink to this headline">¶</a></h2>
The syntax of batch mode is essentially that <a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a>
is used to enter a batch block, and the returned <a class="reference internal" href="ops.html#alembic.operations.BatchOperations" title="alembic.operations.BatchOperations"><code class="xref py py-class docutils literal notranslate">BatchOperations</code></a> context
works just like the regular <a class="reference internal" href="ops.html#alembic.operations.Operations" title="alembic.operations.Operations"><code class="xref py py-class docutils literal notranslate">Operations</code></a> context, except that
the “table name” and “schema name” arguments are omitted.
To support rendering of migration commands in batch mode for autogenerate,
configure the <a class="reference internal" href="api/runtime.html#alembic.runtime.environment.EnvironmentContext.configure.params.render_as_batch" title="alembic.runtime.environment.EnvironmentContext.configure"><code class="xref py py-paramref docutils literal notranslate">EnvironmentContext.configure.render_as_batch</code></a>
flag in <code class="docutils literal notranslate">env.py</code>:
<div class="highlight-default notranslate"><div class="highlight"><pre>context.configure(
 connection=connection,
 target_metadata=target_metadata,
 render_as_batch=True
)
</pre></div>
</div>
Autogenerate will now generate along the lines of:
<div class="highlight-default notranslate"><div class="highlight"><pre>def upgrade():
 ### commands auto generated by Alembic - please adjust! ###
 with op.batch_alter_table(&#39;address&#39;, schema=None) as batch_op:
 batch_op.add_column(sa.Column(&#39;street&#39;, sa.String(length=50), nullable=True))
</pre></div>
</div>
This mode is safe to use in all cases, as the <a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-meth docutils literal notranslate">Operations.batch_alter_table()</code></a>
directive by default only takes place for SQLite; other backends will
behave just as they normally do in the absence of the batch directives.
Note that autogenerate support does not include “offline” mode, where
the <a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.copy_from" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">Operations.batch_alter_table.copy_from</code></a> parameter is used.
The table definition here would need to be entered into migration files
manually if this is needed.
</section>
<section id="batch-mode-with-databases-other-than-sqlite">
<h2>Batch mode with databases other than SQLite<a class="headerlink" href="#batch-mode-with-databases-other-than-sqlite" title="Permalink to this headline">¶</a></h2>
There’s an odd use case some shops have, where the “move and copy” style
of migration is useful in some cases for databases that do already support
ALTER. There’s some cases where an ALTER operation may block access to the
table for a long time, which might not be acceptable. “move and copy” can
be made to work on other backends, though with a few extra caveats.
The batch mode directive will run the “recreate” system regardless of
backend if the flag <code class="docutils literal notranslate">recreate='always'</code> is passed:
<div class="highlight-default notranslate"><div class="highlight"><pre>with op.batch_alter_table(&quot;some_table&quot;, recreate=&#39;always&#39;) as batch_op:
 batch_op.add_column(Column(&#39;foo&#39;, Integer))
</pre></div>
</div>
The issues that arise in this mode are mostly to do with constraints.
Databases such as Postgresql and MySQL with InnoDB will enforce referential
integrity (e.g. via foreign keys) in all cases. Unlike SQLite, it’s not
as simple to turn off referential integrity across the board (nor would it
be desirable). Since a new table is replacing the old one, existing
foreign key constraints which refer to the target table will need to be
unconditionally dropped before the batch operation, and re-created to refer
to the new table afterwards. Batch mode currently does not provide any
automation for this.
The Postgresql database and possibly others also have the behavior such
that when the new table is created, a naming conflict occurs with the
named constraints of the new table, in that they match those of the old
table, and on Postgresql, these names need to be unique across all tables.
The Postgresql dialect will therefore emit a “DROP CONSTRAINT” directive
for all constraints on the old table before the new one is created; this is
“safe” in case of a failed operation because Postgresql also supports
transactional DDL.
Note that also as is the case with SQLite, CHECK constraints need to be
moved over between old and new table manually using the
<a class="reference internal" href="ops.html#alembic.operations.Operations.batch_alter_table.params.table_args" title="alembic.operations.Operations.batch_alter_table"><code class="xref py py-paramref docutils literal notranslate">Operations.batch_alter_table.table_args</code></a> parameter.
</section>
</section>

<div class="clearer"></div>
 </div>
 </div>
 </div>
 <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
 <div class="sphinxsidebarwrapper">
 <div>
 <h3><a href="index.html">Table of Contents</a></h3>
 <ul>
<li><a class="reference internal" href="#">Running “Batch” Migrations for SQLite and Other Databases</a><ul>
<li><a class="reference internal" href="#controlling-table-reflection">Controlling Table Reflection</a></li>
<li><a class="reference internal" href="#dealing-with-constraints">Dealing with Constraints</a><ul>
<li><a class="reference internal" href="#dropping-unnamed-or-named-foreign-key-constraints">Dropping Unnamed or Named Foreign Key Constraints</a></li>
<li><a class="reference internal" href="#including-unnamed-unique-constraints">Including unnamed UNIQUE constraints</a></li>
<li><a class="reference internal" href="#changing-the-type-of-boolean-enum-and-other-implicit-check-datatypes">Changing the Type of Boolean, Enum and other implicit CHECK datatypes</a></li>
<li><a class="reference internal" href="#including-check-constraints">Including CHECK constraints</a></li>
<li><a class="reference internal" href="#dealing-with-referencing-foreign-keys">Dealing with Referencing Foreign Keys</a></li>
</ul>
</li>
<li><a class="reference internal" href="#working-in-offline-mode">Working in Offline Mode</a></li>
<li><a class="reference internal" href="#batch-mode-with-autogenerate">Batch mode with Autogenerate</a></li>
<li><a class="reference internal" href="#batch-mode-with-databases-other-than-sqlite">Batch mode with databases other than SQLite</a></li>
</ul>
</li>
</ul>

</div>
<div id="searchbox" style="display: none" role="search">
 <h3 id="searchlabel">Quick search</h3>
 <div class="searchformwrapper">
 <form class="search" action="search.html" method="get">
 <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
 <input type="submit" value="Go" />
 </form>
 </div>
</div>
<script>$('#searchbox').show(0);</script>
 <div>
 <h4>Previous topic</h4>
 <a href="naming.html"
 title="previous chapter">The Importance of Naming Constraints</a>
 </div>
 <div>
 <h4>Next topic</h4>
 <a href="branches.html"
 title="next chapter">Working with Branches</a>
 </div>
 </div>
 </div>
 <div class="clearer"></div>
 </div>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="genindex.html" title="General Index"
 >index</a></li>
 <li class="right" >
 <a href="py-modindex.html" title="Python Module Index"
 >modules</a> |</li>
 <li class="right" >
 <a href="branches.html" title="Working with Branches"
 >next</a> |</li>
 <li class="right" >
 <a href="naming.html" title="The Importance of Naming Constraints"
 >previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="index.html">Alembic 1.8.1 documentation</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">Running “Batch” Migrations for SQLite and Other Databases</a></li> 
 </ul>
 </div>
 <div class="footer" role="contentinfo">
 &#169; Copyright 2010-2022, Mike Bayer.
 Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.5.0.
 </div>
 </body>
</html>

Fairnetzt-Hochrhein | Vernetzung . Nachhaltigkeit . Gemeinschaft

VERNETZUNG

NACHHALTIGKEIT

GEMEINSCHAFT

VERANTWORTUNG

Willkommen auf Fairnetzt-Hochrhein,

Auf beiden Seiten der Rheingrenze gibt es viele Initiativen, Organisationen, Vereine und auch engagierte Einzelpersonen, welche sich für eine nachhaltige, lebenswerte Zukunft in unserer Region und darüber hinaus einsetzen.

Mit Fairnetzt-Hochrhein.de wollen wir eine Plattform bieten, welche auf lebendige und unkomplizierte Weise es Gruppen aus dem Landkreis Waldshut und aus den Kantonen Aargau und Schaffhausen ermöglicht, Veranstaltungen zu veröffentlichen und andererseits interessierte Menschen erfahren können, was wo stattfindet.

Wir wünschen Euch und uns allen
Ein Gutes Leben und Freude am Abenteuer der Mitgestaltung unserer eigenen Zukunft.

Das Redaktionsteam von Fairnetzt Hochrhein

Direktlink zu: Ihre Veranstaltungen einstellen? oder Anmeldung zum Newsletter?

Veranstaltungen

Dritter Nachhaltigkeitsstammtisch in Dogern

Ziel der Treffen ist, miteinander und voneinander zu lernen, wie man sich in verschiedenen Alltagsbereichen nachhaltiger verhalten kann:
• Einkauf von Dingen des täglichen und langfristigen Bedarfs
• Essen
• Energie sparen und erzeugen
• Unterwegs sein und Reisen, Mobilität
• Informationsaustausch
• …………
Jede*r ist willkommen, sich mit seinen und ihren Fragen und Erfahrungen einzubringen.
Grundidee: wir sind alle in bestimmten Lebensbereichen „Expert*innen“ und können so andere mit unserem Wissen bereichern und bei der Umsetzung im Alltag unterstützen.