diff --git a/doc/source/changeset.rst b/doc/source/changeset.rst index 1ae070e..8aa8307 100644 --- a/doc/source/changeset.rst +++ b/doc/source/changeset.rst @@ -80,10 +80,10 @@ You can create a column with :meth:`~ChangesetColumn.create`: You can pass `primary_key_name`, `index_name` and `unique_name` to the :meth:`~ChangesetColumn.create` method to issue ``ALTER TABLE ADD - CONSTRAINT`` after changing the column. + CONSTRAINT`` after changing the column. For multi columns constraints and other advanced configuration, check the - :ref:`constraint tutorial `. + :ref:`constraint tutorial `. .. versionadded:: 0.6.0 @@ -189,30 +189,30 @@ The following rundowns are true for all constraints classes: cons = PrimaryKeyConstraint('id', 'num', table=self.table) - # Create the constraint - cons.create() + # Create the constraint + cons.create() - # Drop the constraint - cons.drop() + # Drop the constraint + cons.drop() You can also pass in :class:`~sqlalchemy.schema.Column` objects (and table argument can be left out): .. code-block:: python - cons = PrimaryKeyConstraint(col1, col2) + cons = PrimaryKeyConstraint(col1, col2) #. Some dialects support ``CASCADE`` option when dropping constraints: .. code-block:: python - cons = PrimaryKeyConstraint(col1, col2) + cons = PrimaryKeyConstraint(col1, col2) - # Create the constraint - cons.create() + # Create the constraint + cons.create() - # Drop the constraint - cons.drop(cascade=True) + # Drop the constraint + cons.drop(cascade=True) .. note:: SQLAlchemy Migrate will try to guess the name of the constraints for @@ -244,12 +244,12 @@ Foreign key constraints: .. code-block:: python from migrate.changeset.constraint import ForeignKeyConstraint - + cons = ForeignKeyConstraint([table.c.fkey], [othertable.c.id]) - + # Create the constraint cons.create() - + # Drop the constraint cons.drop() @@ -258,9 +258,9 @@ Check constraints: .. code-block:: python from migrate.changeset.constraint import CheckConstraint - + cons = CheckConstraint('id > 3', columns=[table.c.id]) - + # Create the constraint cons.create() @@ -272,7 +272,7 @@ Unique constraints: .. code-block:: python from migrate.changeset.constraint import UniqueConstraint - + cons = UniqueConstraint('id', 'age', table=self.table) # Create the constraint diff --git a/doc/source/versioning.rst b/doc/source/versioning.rst index dd413d3..7b30cd3 100644 --- a/doc/source/versioning.rst +++ b/doc/source/versioning.rst @@ -75,7 +75,7 @@ script applied to the database increments this version number. You can retrieve a database's current :term:`version`:: $ 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 assumes the database is empty or does only contain schema elements (tables, views, @@ -140,7 +140,7 @@ Our first change script will create a simple table account = Table( 'account', meta, - Column('id', Integer, primary_key=True), + Column('id', Integer, primary_key=True), Column('login', String(40)), Column('passwd', String(40)), ) @@ -172,7 +172,7 @@ Our change script predefines two functions, currently empty: Column('login', String(40)), Column('passwd', String(40)), ) - + def upgrade(migrate_engine): meta.bind = migrate_engine @@ -251,9 +251,9 @@ Our :term:`repository's ` :term:`version` is:: 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 @@ -363,7 +363,7 @@ your application - the same SQL should be generated every time, despite any changes to your app's source code. You don't want your change scripts' behavior changing when your source code does. -.. warning:: +.. warning:: **Consider the following example of what NOT to do** @@ -372,7 +372,7 @@ changing when your source code does. .. code-block:: python from sqlalchemy import * - + meta = MetaData() table = Table('mytable', meta, Column('id', Integer, primary_key=True), @@ -381,7 +381,7 @@ changing when your source code does. ... and uses this file to create a table in a change script: .. code-block:: python - + from sqlalchemy import * from migrate import * import model @@ -390,7 +390,7 @@ changing when your source code does. model.meta.bind = migrate_engine def downgrade(migrate_engine): - model.meta.bind = migrate_engine + model.meta.bind = migrate_engine model.table.drop() This runs successfully the first time. But what happens if we change the @@ -399,7 +399,7 @@ changing when your source code does. .. code-block:: python from sqlalchemy import * - + meta = MetaData() table = Table('mytable', meta, Column('id', Integer, primary_key=True), @@ -448,7 +448,7 @@ database. Use engine.name to get the name of the database you're working with >>> from sqlalchemy import * >>> from migrate import * - >>> + >>> >>> engine = create_engine('sqlite:///:memory:') >>> engine.name 'sqlite' @@ -537,7 +537,7 @@ function names match equivalent shell commands. You can use this to help integrate SQLAlchemy Migrate with your existing update process. For example, the following commands are similar: - + *From the command line*:: $ migrate help help @@ -553,9 +553,9 @@ For example, the following commands are similar: migrate.versioning.api.help('help') # Output: # %prog help COMMAND - # + # # Displays help on a given command. - + .. _migrate.versioning.api: module-migrate.versioning.api.html @@ -631,7 +631,7 @@ One may also want to specify custom themes. API functions accept ``templates_theme`` for this purpose (which defaults to `default`) Example:: - + /home/user/templates/manage $ ls default.py_tmpl pylons.py_tmpl