x/sqlalchemy-migrate
Code Issues Proposed changes

document adding/droping columns (fixes issue 104)

Browse Source
This commit is contained in:
Jan Dittberner
2011-10-29 21:59:11 +02:00
parent 1367004a17
commit 2bc520eaa6
1 changed files with 314 additions and 214 deletions
Download Patch File Download Diff File Expand all files Collapse all files

438
docs/versioning.rst
View File

@@ -9,8 +9,9 @@ Database schema versioning workflow
SQLAlchemy migrate provides the :mod:`migrate.versioning` API that is SQLAlchemy migrate provides the :mod:`migrate.versioning` API that is
also available as the :ref:`migrate <command-line-usage>` command. also available as the :ref:`migrate <command-line-usage>` command.
Purpose of this package is frontend for migrations. It provides commands Purpose of this package is frontend for migrations. It provides commands to
to manage migrate repository and database selection aswell as script versioning. manage migrate :term:`repository` and database selection as well as script
versioning.
Project setup Project setup
@@ -21,73 +22,76 @@ Project setup
Create a change repository Create a change repository
-------------------------- --------------------------
To begin, we'll need to create a *repository* for our To begin, we'll need to create a :term:`repository` for our project.
project.
All work with repositories is done using the :ref:`migrate <command-line-usage>` command. Let's All work with repositories is done using the :ref:`migrate
create our project's repository:: <command-line-usage>` command. Let's create our project's repository::
$ migrate create my_repository "Example project" $ migrate create my_repository "Example project"
This creates an initially empty repository relative to current directory at This creates an initially empty :term:`repository` relative to current
my_repository/ named `Example project`. directory at :file:`my_repository/` named `Example project`.
The repository directory The :term:`repository` directory contains a sub directory :file:`versions` that
contains a sub directory :file:`versions` that will store the :ref:`schema versions <changeset-system>`, will store the :ref:`schema versions <changeset-system>`, a configuration file
a configuration file :file:`migrate.cfg` that contains :file:`migrate.cfg` that contains :ref:`repository configuration
:ref:`repository configuration <repository_configuration>` and a script :ref:`manage.py <project_management_script>` <repository_configuration>` and a script :ref:`manage.py
that has the same functionality as the :ref:`migrate <command-line-usage>` command but is <project_management_script>` that has the same functionality as the
preconfigured with repository specific parameters. :ref:`migrate <command-line-usage>` command but is preconfigured with
repository specific parameters.
.. note:: .. note::
Repositories are associated with a single database schema, Repositories are associated with a single database schema, and store
and store collections of change scripts to manage that schema. The collections of change scripts to manage that schema. The scripts in a
scripts in a repository may be applied to any number of databases. :term:`repository` may be applied to any number of databases. Each
Each repository has an unique name. This name is used to identify the :term:`repository` has an unique name. This name is used to identify the
repository we're working with. :term:`repository` we're working with.
Version control a database Version control a database
-------------------------- --------------------------
Next we need to declare database to be under version control. Next we need to declare database to be under version control. Information on a
Information on a database's version is stored in the database database's version is stored in the database itself; declaring a database to be
itself; declaring a database to be under version control creates a under version control creates a table named **migrate_version** and associates
table named **migrate_version** and associates it with your repository. it with your :term:`repository`.
The database is specified as a `SQLAlchemy database url`_. The database is specified as a `SQLAlchemy database url`_.
.. _`sqlalchemy database url`: .. _`sqlalchemy database url`:
http://www.sqlalchemy.org/docs/05/dbengine.html#create-engine-url-arguments http://www.sqlalchemy.org/docs/core/engines.html#database-urls
:: The :option:`version_control` command assigns a specified database with a
:term:`repository`::
$ python my_repository/manage.py version_control sqlite:///project.db my_repository $ python my_repository/manage.py version_control sqlite:///project.db my_repository
We can have any number of databases under this repository's version We can have any number of databases under this :term:`repository's
control. <repository>` version control.
Each schema has a version that SQLAlchemy Migrate manages. Each change Each schema has a :term:`version` that SQLAlchemy Migrate manages. Each change
script applied to the database increments this version number. You can script applied to the database increments this version number. You can retrieve
see a database's current version:: a database's current :term:`version`::
$ python my_repository/manage.py db_version sqlite:///project.db my_repository $ python my_repository/manage.py db_version sqlite:///project.db my_repository
0 0
A freshly versioned database begins at version 0 by default. This A freshly versioned database begins at version 0 by default. This assumes the
assumes the database is empty. (If this is a bad assumption, you can database is empty or does only contain schema elements (tables, views,
specify the version at the time the database is declared under version constraints, indices, ...) that will not be affected by the changes in the
control, with the "version_control" command.) We'll see that creating :term:`repository`. (If this is a bad assumption, you can specify the
and applying change scripts changes the database's version number. :term:`version` at the time the database is put under version control, with the
:option:`version_control` command.) We'll see that creating and applying change
scripts changes the database's :term:`version` number.
Similarly, we can also see the latest version available in a Similarly, we can also see the latest :term:`version` available in a
repository with the command:: :term:`repository` with the command::
$ python my_repository/manage.py version my_repository $ python my_repository/manage.py version my_repository
0 0
We've entered no changes so far, so our repository cannot upgrade a We've entered no changes so far, so our :term:`repository` cannot upgrade a
database past version 0. database past version 0.
Project management script Project management script
@@ -95,36 +99,37 @@ Project management script
.. _project_management_script: .. _project_management_script:
Many commands need to know our project's database url and repository Many commands need to know our project's database url and :term:`repository`
path - typing them each time is tedious. We can create a script for path - typing them each time is tedious. We can create a script for our project
our project that remembers the database and repository we're using, that remembers the database and :term:`repository` we're using, and use it to
and use it to perform commands:: perform commands::
$ migrate manage manage.py --repository=my_repository --url=sqlite:///project.db $ migrate manage manage.py --repository=my_repository --url=sqlite:///project.db
$ python manage.py db_version $ python manage.py db_version
0 0
The script manage.py was created. All commands we perform with it are The script :file:`manage.py` was created. All commands we perform with it are
the same as those performed with the :ref:`migrate <command-line-usage>` tool, using the the same as those performed with the :ref:`migrate <command-line-usage>` tool,
repository and database connection entered above. The difference using the :term:`repository` and database connection entered above. The
between the script :file:`manage.py` in the current directory and the difference between the script :file:`manage.py` in the current directory and
script inside the repository is, that the one in the current directory the script inside the repository is, that the one in the current directory has
has the database URL preconfigured. the database URL preconfigured.
.. note:: .. note::
Parameters specified in manage.py should be the same as in :ref:`versioning api <versioning-api>`. Parameters specified in manage.py should be the same as in :ref:`versioning
Preconfigured parameter should just be omitted from :ref:`migrate <command-line-usage>` command. api <versioning-api>`. Preconfigured parameter should just be omitted from
:ref:`migrate <command-line-usage>` command.
Making schema changes Making schema changes
===================== =====================
All changes to a database schema under version control should be done All changes to a database schema under version control should be done via
via change scripts - you should avoid schema modifications (creating change scripts - you should avoid schema modifications (creating tables, etc.)
tables, etc.) outside of change scripts. This allows you to determine outside of change scripts. This allows you to determine what the schema looks
what the schema looks like based on the version number alone, and like based on the version number alone, and helps ensure multiple databases
helps ensure multiple databases you're working with are consistent. you're working with are consistent.
Create a change script Create a change script
---------------------- ----------------------
@@ -133,7 +138,8 @@ Our first change script will create a simple table
.. code-block:: python .. code-block:: python
account = Table('account', meta, account = Table(
'account', meta,
Column('id', Integer, primary_key=True), Column('id', Integer, primary_key=True),
Column('login', String(40)), Column('login', String(40)),
Column('passwd', String(40)), Column('passwd', String(40)),
@@ -152,62 +158,72 @@ Edit the change script
---------------------- ----------------------
Our change script predefines two functions, currently empty: Our change script predefines two functions, currently empty:
:func:`upgrade` and :func:`downgrade`. We'll fill those in :py:func:`upgrade` and :py:func:`downgrade`. We'll fill those in:
.. code-block:: python .. code-block:: python
from sqlalchemy import * from sqlalchemy import Table, Column, Integer, String, MetaData
from migrate import *
meta = MetaData() meta = MetaData()
account = Table('account', meta, account = Table(
'account', meta,
Column('id', Integer, primary_key=True), Column('id', Integer, primary_key=True),
Column('login', String(40)), Column('login', String(40)),
Column('passwd', String(40)), Column('passwd', String(40)),
) )
def upgrade(migrate_engine): def upgrade(migrate_engine):
meta.bind = migrate_engine meta.bind = migrate_engine
account.create() account.create()
def downgrade(migrate_engine): def downgrade(migrate_engine):
meta.bind = migrate_engine meta.bind = migrate_engine
account.drop() account.drop()
As you might have guessed, :func:`upgrade` upgrades the database to the next .. note::
version. This function should contain the :ref:`schema changes<changeset-system>` we want to perform
(in our example we're creating a table).
:func:`downgrade` should reverse changes made The generated script contains * imports from sqlalchemy and migrate. You
by :func:`upgrade`. You'll need to write both functions for every change should tailor the imports to fit your actual demand.
script. (Well, you don't *have* to write downgrade, but you won't be
able to revert to an older version of the database or test your As you might have guessed, :py:func:`upgrade` upgrades the database to the next
scripts without it.) version. This function should contain the :ref:`schema changes
<changeset-system>` we want to perform (in our example we're creating a
table).
:py:func:`downgrade` should reverse changes made by :py:func:`upgrade`. You'll
need to write both functions for every change script. (Well, you don't *have*
to write downgrade, but you won't be able to revert to an older version of the
database or test your scripts without it.) If you really don't want to support
downgrades it is a good idea to raise a :py:class:`NotImplementedError` or some
equivalent custom exception. If you let :py:func:`downgrade` pass silently you
might observe undesired behaviour for subsequent downgrade operations if
downgrading multiple :term:`versions <version>`.
.. note:: .. note::
As you can see, **migrate_engine** is passed to both functions. As you can see, **migrate_engine** is passed to both functions. You should
You should use this in your change scripts, rather use this in your change scripts, rather than creating your own engine.
than creating your own engine.
.. warning:: .. warning::
You should be very careful about importing files from the rest of your You should be very careful about importing files from the rest of your
application, as your change scripts might break when your application application, as your change scripts might break when your application
changes. More about `writing scripts with consistent behavior`_. changes. Read more about `writing scripts with consistent behavior`_.
Test the change script Test the change script
------------------------ ------------------------
Change scripts should be tested before they are committed. Testing a Change scripts should be tested before they are committed. Testing a script
script will run its :func:`upgrade` and :func:`downgrade` functions on a specified will run its :func:`upgrade` and :func:`downgrade` functions on a specified
database; you can ensure the script runs without error. You should be database; you can ensure the script runs without error. You should be testing
testing on a test database - if something goes wrong here, you'll need on a test database - if something goes wrong here, you'll need to correct it by
to correct it by hand. If the test is successful, the database should hand. If the test is successful, the database should appear unchanged after
appear unchanged after :func:`upgrade` and :func:`downgrade` run. :func:`upgrade` and :func:`downgrade` run.
To test the script:: To test the script::
@@ -216,17 +232,31 @@ To test the script::
Downgrading... done Downgrading... done
Success Success
Our script runs on our database (``sqlite:///project.db``, as Our script runs on our database (:file:`sqlite:///project.db`, as specified in
specified in manage.py) without any errors. :file:`manage.py`) without any errors.
Our repository's version is:: Our :term:`repository's <repository>` :term:`version` is::
$ python manage.py version $ python manage.py version
1 1
.. note::
Due to #41 the database must be exactly one :term:`version` behind the
:term:`repository` :term:`version`.
.. _production testing warning:
.. warning:: .. warning::
test command executes actual script, be sure you are NOT doing this on production database. The :option:`test` command executes actual scripts, be sure you are *NOT*
doing this on production database.
If you need to test production changes you should:
#. get a dump of your production database
#. import the dump into an empty database
#. run :option:`test` or :option:`upgrade` on that copy
Upgrade the database Upgrade the database
@@ -235,12 +265,13 @@ Upgrade the database
Now, we can apply this change script to our database:: Now, we can apply this change script to our database::
$ python manage.py upgrade $ python manage.py upgrade
0 -> 1... done 0 -> 1...
done
This upgrades the database (``sqlite:///project.db``, as specified This upgrades the database (:file:`sqlite:///project.db`, as specified when we
when we created manage.py above) to the latest available version. (We created :file:`manage.py` above) to the latest available :term:`version`. (We
could also specify a version number if we wished, using the ``--version`` could also specify a version number if we wished, using the :option:`--version`
option.) We can see the database's version number has changed, and our option.) We can see the database's :term:`version` number has changed, and our
table has been created:: table has been created::
$ python manage.py db_version $ python manage.py db_version
@@ -248,37 +279,97 @@ table has been created::
$ sqlite3 project.db $ sqlite3 project.db
sqlite> .tables sqlite> .tables
account migrate_version account migrate_version
sqlite> .schema account
CREATE TABLE account (
id INTEGER NOT NULL,
login VARCHAR(40),
passwd VARCHAR(40),
PRIMARY KEY (id)
);
Our account table was created - success!
Modifying existing tables
-------------------------
After we have initialized the database schema we now want to add another Column
to the `account` table that we already have in our schema.
First start a new :term:`changeset` by the commands learned above::
$ python manage.py script "Add email column"
This creates a new :term:`changeset` template. Edit the resulting script
:file:`my_repository/versions/002_Add_email_column.py`:
.. code-block:: python
from sqlalchemy import Table, MetaData, String, Column
def upgrade(migrate_engine):
meta = MetaData(bind=migrate_engine)
account = Table('account', meta, autoload=True)
emailc = Column('email', String(128))
emailc.create(account)
def downgrade(migrate_engine):
meta = MetaData(bind=migrate_engine)
account = Table('account', meta, autoload=True)
account.c.email.drop()
As we can see in this example we can (and should) use SQLAlchemy's schema
reflection (autoload) mechanism to reference existing schema objects. We could
have defined the table objects as they are expected before upgrade or downgrade
as well but this would have been more work and is not as convenient.
We can now apply the changeset to :file:`sqlite:///project.db`::
$ python manage.py upgrade
1 -> 2...
done
and get the following expected result::
$ sqlite3 project.db
sqlite> .schema account
CREATE TABLE account (
id INTEGER NOT NULL,
login VARCHAR(40),
passwd VARCHAR(40), email VARCHAR(128),
PRIMARY KEY (id)
);
Our account table was created - success! As our application evolves,
we can create more change scripts using a similar process.
Writing change scripts Writing change scripts
====================== ======================
By default, change scripts may do anything any other SQLAlchemy As our application evolves, we can create more change scripts using a similar
program can do. process.
SQLAlchemy Migrate extends SQLAlchemy with several operations used to By default, change scripts may do anything any other SQLAlchemy program can do.
change existing schemas - ie. ``ALTER TABLE`` stuff. See
:ref:`changeset <changeset-system>` documentation for details. SQLAlchemy Migrate extends SQLAlchemy with several operations used to change
existing schemas - ie. ``ALTER TABLE`` stuff. See :ref:`changeset
<changeset-system>` documentation for details.
Writing scripts with consistent behavior Writing scripts with consistent behavior
---------------------------------------- ----------------------------------------
Normally, it's important to write change scripts in a way that's Normally, it's important to write change scripts in a way that's independent of
independent of your application - the same SQL should be generated your application - the same SQL should be generated every time, despite any
every time, despite any changes to your app's source code. You don't changes to your app's source code. You don't want your change scripts' behavior
want your change scripts' behavior changing when your source code changing when your source code does.
does.
.. warning:: .. warning::
**Consider the following example of what NOT to do** **Consider the following example of what NOT to do**
Let's say your application defines a table in the :file:`model.py` file: Let's say your application defines a table in the :file:`model.py` file:
.. code-block:: python .. code-block:: python
from sqlalchemy import * from sqlalchemy import *
@@ -287,9 +378,9 @@ Let's say your application defines a table in the :file:`model.py` file:
Column('id', Integer, primary_key=True), Column('id', Integer, primary_key=True),
) )
... and uses this file to create a table in a change script: ... and uses this file to create a table in a change script:
.. code-block:: python .. code-block:: python
from sqlalchemy import * from sqlalchemy import *
from migrate import * from migrate import *
@@ -302,10 +393,10 @@ Let's say your application defines a table in the :file:`model.py` file:
model.meta.bind = migrate_engine model.meta.bind = migrate_engine
model.table.drop() model.table.drop()
This runs successfully the first time. But what happens if we change This runs successfully the first time. But what happens if we change the
the table definition in :file:`model.py`? table definition in :file:`model.py`?
.. code-block:: python .. code-block:: python
from sqlalchemy import * from sqlalchemy import *
@@ -315,9 +406,9 @@ the table definition in :file:`model.py`?
Column('data', String(42)), Column('data', String(42)),
) )
We'll create a new column with a matching change script We'll create a new column with a matching change script
.. code-block:: python .. code-block:: python
from sqlalchemy import * from sqlalchemy import *
from migrate import * from migrate import *
@@ -331,27 +422,27 @@ We'll create a new column with a matching change script
model.meta.bind = migrate_engine model.meta.bind = migrate_engine
model.table.drop() model.table.drop()
This appears to run fine when upgrading an existing database - but the
first script's behavior changed! Running all our change scripts on a new
database will result in an error - the first script creates the table based
on the new definition, with both columns; the second cannot add the column
because it already exists.
This appears to run fine when upgrading an existing database - but the To avoid the above problem, you should use SQLAlchemy schema reflection as
first script's behavior changed! Running all our change scripts on a shown above or copy-paste your table definition into each change script
new database will result in an error - the first script creates the rather than importing parts of your application.
table based on the new definition, with both columns; the second
cannot add the column because it already exists.
To avoid the above problem, you should copy-paste your table .. note::
definition into each change script rather than importing parts of your Sometimes it is enough to just reflect tables with SQLAlchemy instead
application. of copy-pasting - but remember, explicit is better than implicit!
.. note:: Sometimes it is enough to just reflect tables with SQLAlchemy instead of copy-pasting - but remember, explicit is better than implicit!
Writing for a specific database Writing for a specific database
------------------------------- -------------------------------
Sometimes you need to write code for a specific database. Migrate Sometimes you need to write code for a specific database. Migrate scripts can
scripts can run under any database, however - the engine you're given run under any database, however - the engine you're given might belong to any
might belong to any database. Use engine.name to get the name of the database. Use engine.name to get the name of the database you're working with
database you're working with
.. code-block:: python .. code-block:: python
@@ -362,24 +453,24 @@ database you're working with
>>> engine.name >>> engine.name
'sqlite' 'sqlite'
Writings .sql scripts Writings .sql scripts
--------------------- ---------------------
You might prefer to write your change scripts in SQL, as .sql files, You might prefer to write your change scripts in SQL, as .sql files, rather
rather than as Python scripts. SQLAlchemy-migrate can work with that:: than as Python scripts. SQLAlchemy-migrate can work with that::
$ python manage.py version $ python manage.py version
1 1
$ python manage.py script_sql postgres $ python manage.py script_sql postgresql
This creates two scripts This creates two scripts
:file:`my_repository/versions/002_postgresql_upgrade.sql` and :file:`my_repository/versions/002_postgresql_upgrade.sql` and
:file:`my_repository/versions/002_postgresql_downgrade.sql`, one for :file:`my_repository/versions/002_postgresql_downgrade.sql`, one for each
each *operation*, or function defined in a Python change script - *operation*, or function defined in a Python change script - upgrade and
upgrade and downgrade. Both are specified to run with Postgres downgrade. Both are specified to run with PostgreSQL databases - we can add
databases - we can add more for different databases if we like. Any more for different databases if we like. Any database defined by SQLAlchemy may
database defined by SQLAlchemy may be used here - ex. sqlite, be used here - ex. sqlite, postgresql, oracle, mysql...
postgres, oracle, mysql...
.. _command-line-usage: .. _command-line-usage:
@@ -389,14 +480,17 @@ Command line usage
.. currentmodule:: migrate.versioning.shell .. currentmodule:: migrate.versioning.shell
:command:`migrate` command is used for API interface. For list of commands and help use:: :command:`migrate` command is used for API interface. For list of commands and
help use::
$ migrate --help $ migrate --help
:program:`migrate` command exectues :func:`main` function. :command:`migrate` command executes :func:`main` function.
For ease of usage, generate your own :ref:`project management script <project_management_script>`, For ease of usage, generate your own :ref:`project management script
which calls :func:`main` function with keywords arguments. <project_management_script>`, which calls :func:`main
You may want to specify `url` and `repository` arguments which almost all API functions require. <migrate.versioning.shell.main>` function with keywords arguments. You may want
to specify `url` and `repository` arguments which almost all API functions
require.
If api command looks like:: If api command looks like::
@@ -422,12 +516,13 @@ you have first two slots filed, and command line usage would look like::
Command line parsing refactored: positional parameters usage Command line parsing refactored: positional parameters usage
Whole command line parsing was rewriten from scratch with use of OptionParser. Whole command line parsing was rewriten from scratch with use of OptionParser.
Options passed as kwargs to :func:`~migrate.versioning.shell.main` are now parsed correctly. Options passed as kwargs to :func:`~migrate.versioning.shell.main` are now
Options are passed to commands in the following priority (starting from highest): parsed correctly. Options are passed to commands in the following priority
(starting from highest):
- optional (given by ``--some_option`` in commandline) - optional (given by :option:`--some_option` in commandline)
- positional arguments - positional arguments
- kwargs passed to migrate.versioning.shell.main - kwargs passed to :func:`migrate.versioning.shell.main`
Python API Python API
@@ -470,10 +565,10 @@ For example, the following commands are similar:
Experimental commands Experimental commands
===================== =====================
Some interesting new features to create SQLAlchemy db models from Some interesting new features to create SQLAlchemy db models from existing
existing databases and vice versa were developed by Christian Simms databases and vice versa were developed by Christian Simms during the
during the development of SQLAlchemy-migrate 0.4.5. These features are development of SQLAlchemy-migrate 0.4.5. These features are roughly documented
roughly documented in a `thread in migrate-users`_. in a `thread in migrate-users`_.
.. _`thread in migrate-users`: .. _`thread in migrate-users`:
http://groups.google.com/group/migrate-users/browse_thread/thread/a5605184e08abf33#msg_85c803b71b29993f http://groups.google.com/group/migrate-users/browse_thread/thread/a5605184e08abf33#msg_85c803b71b29993f
@@ -488,46 +583,52 @@ Here are the commands' descriptions as given by ``migrate help <command>``:
- ``make_update_script_for_model``: Create a script changing the old - ``make_update_script_for_model``: Create a script changing the old
Python model to the new (current) Python model, sending to stdout. Python model to the new (current) Python model, sending to stdout.
As this sections headline says: These features are EXPERIMENTAL. Take As this sections headline says: These features are *EXPERIMENTAL*. Take the
the necessary arguments to the commands from the output of ``migrate necessary arguments to the commands from the output of ``migrate
help <command>``. help <command>``.
Repository configuration Repository configuration
======================== ========================
SQLAlchemy-migrate repositories can be configured in their migrate.cfg SQLAlchemy-migrate :term:`repositories <repository>` can be configured in their
files. The initial configuration is performed by the `migrate create` :file:`migrate.cfg` files. The initial configuration is performed by the
call explained in :ref:`Create a change repository `migrate create` call explained in :ref:`Create a change repository
<create_change_repository>`. The following options are available <create_change_repository>`. The following options are available currently:
currently:
- `repository_id` Used to identify which repository this database is - :option:`repository_id` Used to identify which repository this database is
versioned under. You can use the name of your project. versioned under. You can use the name of your project.
- `version_table` The name of the database table used to track the - :option:`version_table` The name of the database table used to track the
schema version. This name shouldn't already be used by your schema version. This name shouldn't already be used by your project. If this
project. If this is changed once a database is under version is changed once a database is under version control, you'll need to change
control, you'll need to change the table name in each database too. the table name in each database too.
- `required_dbs` When committing a change script, SQLAlchemy-migrate - :option:`required_dbs` When committing a change script, SQLAlchemy-migrate
will attempt to generate the sql for all supported databases; will attempt to generate the sql for all supported databases; normally, if
normally, if one of them fails - probably because you don't have one of them fails - probably because you don't have that database installed -
that database installed - it is ignored and the commit continues, it is ignored and the commit continues, perhaps ending successfully.
perhaps ending successfully. Databases in this list MUST compile Databases in this list MUST compile successfully during a commit, or the
successfully during a commit, or the entire commit will fail. List entire commit will fail. List the databases your application will actually be
the databases your application will actually be using to ensure your using to ensure your updates to that database work properly. This must be a
updates to that database work properly. This must be a list; list; example: `['postgres', 'sqlite']`
example: `['postgres', 'sqlite']` - :option:`use_timestamp_numbering` When creating new change scripts, Migrate
will stamp the new script with a version number. By default this is
latest_version + 1. You can set this to 'true' to tell Migrate to use the UTC
timestamp instead.
.. versionadded:: 0.7.2
.. _custom-templates: .. _custom-templates:
Customize templates Customize templates
=================== ===================
Users can pass ``templates_path`` to API functions to provide customized templates path. Users can pass ``templates_path`` to API functions to provide customized
Path should be a collection of templates, like ``migrate.versioning.templates`` package directory. templates path. Path should be a collection of templates, like
``migrate.versioning.templates`` package directory.
One may also want to specify custom themes. API functions accept ``templates_theme`` for this purpose (which defaults to `default`) One may also want to specify custom themes. API functions accept
``templates_theme`` for this purpose (which defaults to `default`)
Example:: Example::
@@ -537,5 +638,4 @@ Example::
/home/user/templates/manage $ migrate manage manage.py --templates_path=/home/user/templates --templates_theme=pylons /home/user/templates/manage $ migrate manage manage.py --templates_path=/home/user/templates --templates_theme=pylons
.. versionadded:: 0.6.0 .. versionadded:: 0.6.0