# TODO:
# --dialect - name of dialect when --sql mode is set - *no DB connections
# should occur, add this to env.py templates as a conditional*
- # --init-version-table - add CREATE for version table
positional_help = {
'directory':"location of scripts directory",
'revision':"revision identifier"
else "non-transactional")
if self.as_sql and self.transactional_ddl:
- self.static_output("BEGIN;\n")
+ self.static_output("BEGIN;")
current_rev = False
for change, prev_rev, rev in self._migrations_fn(
_version.drop(self.connection)
if self.as_sql and self.transactional_ddl:
- self.static_output("COMMIT;\n")
+ self.static_output("COMMIT;")
def _exec(self, construct, *args, **kw):
if isinstance(construct, basestring):
raise Exception("Execution arguments not allowed with as_sql")
self.static_output(unicode(
construct.compile(dialect=self.dialect)
- ).replace("\t", " ") + ";")
+ ).replace("\t", " ").strip() + ";")
else:
self.connection.execute(construct, *args, **kw)
return self.connection.dialect
def static_output(self, text):
- self.output_buffer.write(text + "\n")
+ self.output_buffer.write(text + "\n\n")
def execute(self, sql):
self._exec(sql)
INFO [alembic.context] Will assume transactional DDL.
BEGIN;
- INFO [alembic.context] Running upgrade None -> 1975ea83b712
+ CREATE TABLE alembic_version (
+ version_num VARCHAR(32) NOT NULL
+ );
+ INFO [alembic.context] Running upgrade None -> 1975ea83b712
CREATE TABLE account (
id SERIAL NOT NULL,
name VARCHAR(50) NOT NULL,
description VARCHAR(200),
PRIMARY KEY (id)
- )
+ );
- ;
INFO [alembic.context] Running upgrade 1975ea83b712 -> ae1027a6acf
ALTER TABLE account ADD COLUMN last_transaction_date TIMESTAMP WITHOUT TIME ZONE;
+
INSERT INTO alembic_version (version_num) VALUES ('ae1027a6acf');
+
COMMIT;
+
While the logging configuration dumped to standard error, the actual script was dumped to standard output -
so typically we'd be using output redirection to generate a script::
There's a theory of database migrations that says that the revisions in existence for a database should be
able to go from an entirely blank schema to the finished product, and back again. Alembic can roll
this way. Though we think it's kind of overkill, considering that SQLAlchemy itself can emit
-the full CREATE statements for any given model using :meth:`.MetaData.create_all`. If you check out
+the full CREATE statements for any given model using :meth:`~sqlalchemy.schema.MetaData.create_all`. If you check out
a copy of an application, running this will give you the entire database in one shot, without the need
to run through all those migration files, which are instead tailored towards applying incremental
changes to an existing database.
-Alembic can integrate with a :meth:`.MetaData.create_all` script quite easily. After running the
+Alembic can integrate with a :meth:`~sqlalchemy.schema.MetaData.create_all` script quite easily. After running the
create operation, tell Alembic to create a new version table, and to stamp it with the most recent
revision (i.e. ``head``)::