x/sqlalchemy-migrate
Code Issues Proposed changes

Convert tabs to spaces in a couple of rst files

Browse Source 
These restructured text files mostly use spaces, but a few stray
tabs crept in.  Change them for consistency.

Change-Id: I89f390d02c737798007423a5126d81ad3d9e032e
This commit is contained in:
David Ripton 2014-02-26 15:00:50 -05:00
parent 21fcdad0f4
commit 82f739b96f
2 changed files with 33 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
doc/source/changeset.rst
View File

@ -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 <constraint-tutorial>`.
:ref:`constraint tutorial <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

30
doc/source/versioning.rst
View File

@ -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 <repository>` :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