* Provide a library of ALTER constructs that can be used by any SQLAlchemy
application. The DDL constructs build upon SQLAlchemy's own DDLElement base
and can be used standalone by any application or script.
-* At long last, bring SQLite and its inablity to ALTER things into the fold,
+* At long last, bring SQLite and its inability to ALTER things into the fold,
but in such a way that SQLite's very special workflow needs are accommodated
in an explicit way that makes the most of a bad situation, through the
concept of a "batch" migration, where multiple changes to a table can
some_param = context.config.get_main_option("my option")
- When invoking Alembic programatically, a new
+ When invoking Alembic programmatically, a new
:class:`.Config` can be created by passing
the name of an .ini file to the constructor::
don't otherwise specify a new type, as well as for
when nullability is being changed on a SQL Server
column. It is also used if the type is a so-called
- SQLlchemy "schema" type which may define a constraint (i.e.
+ SQLAlchemy "schema" type which may define a constraint (i.e.
:class:`~sqlalchemy.types.Boolean`,
:class:`~sqlalchemy.types.Enum`),
so that the constraint can be dropped.
)
Additionally, when passing the statement as a plain string, it is first
- coerceed into a :func:`sqlalchemy.sql.expression.text` construct
+ coerced into a :func:`sqlalchemy.sql.expression.text` construct
before being passed along. In the less likely case that the
literal SQL string contains a colon, it must be escaped with a
backslash, as::
don't otherwise specify a new type, as well as for
when nullability is being changed on a SQL Server
column. It is also used if the type is a so-called
- SQLlchemy "schema" type which may define a constraint (i.e.
+ SQLAlchemy "schema" type which may define a constraint (i.e.
:class:`~sqlalchemy.types.Boolean`,
:class:`~sqlalchemy.types.Enum`),
so that the constraint can be dropped.
)
Additionally, when passing the statement as a plain string, it is first
- coerceed into a :func:`sqlalchemy.sql.expression.text` construct
+ coerced into a :func:`sqlalchemy.sql.expression.text` construct
before being passed along. In the less likely case that the
literal SQL string contains a colon, it must be escaped with a
backslash, as::
don't otherwise specify a new type, as well as for
when nullability is being changed on a SQL Server
column. It is also used if the type is a so-called
- SQLlchemy "schema" type which may define a constraint (i.e.
+ SQLAlchemy "schema" type which may define a constraint (i.e.
:class:`~sqlalchemy.types.Boolean`,
:class:`~sqlalchemy.types.Enum`),
so that the constraint can be dropped.
)
Additionally, when passing the statement as a plain string, it is first
- coerceed into a :func:`sqlalchemy.sql.expression.text` construct
+ coerced into a :func:`sqlalchemy.sql.expression.text` construct
before being passed along. In the less likely case that the
literal SQL string contains a colon, it must be escaped with a
backslash, as::
) -> Tuple[Optional[str], Optional[_RevisionOrBase]]:
"""
Parse downgrade command syntax :target to retrieve the target revision
- and branch label (if any) given the :current_revisons stamp of the
+ and branch label (if any) given the :current_revisions stamp of the
database.
Returns a tuple (branch_label, target_revision) where branch_label
is a string from the command specifying the branch to consider (or
None if no branch given), and target_revision is a Revision object
- which the command refers to. target_revsions is None if the command
+ which the command refers to. target_revisions is None if the command
refers to 'base'. The target may be specified in absolute form, or
relative to :current_revisions.
"""
if not symbol_list:
# check the case where there are multiple branches
# but there is currently a single heads, since all
- # other branch heads are dependant of the current
+ # other branch heads are dependent of the current
# single heads.
all_current = cast(
Set[Revision], self._get_all_current(cr_tuple)
) -> Tuple[Optional[_RevisionOrBase], ...]:
"""
Parse upgrade command syntax :target to retrieve the target revision
- and given the :current_revisons stamp of the database.
+ and given the :current_revisions stamp of the database.
Returns a tuple of Revision objects which should be iterated/upgraded
to. The target may be specified in absolute form, or relative to
=====================
A **branch** describes a point in a migration stream when two or more
-versions refer to the same parent migration as their anscestor. Branches
+versions refer to the same parent migration as their ancestor. Branches
occur naturally when two divergent source trees, both containing Alembic
revision files created independently within those source trees, are merged
together into one. When this occurs, the challenge of a branch is to **merge** the
We create the merge file using ``alembic merge``; with this command, we can
pass to it an argument such as ``heads``, meaning we'd like to merge all
-heads. Or, we can pass it individual revision numbers sequentally::
+heads. Or, we can pass it individual revision numbers sequentially::
$ alembic merge -m "merge ae1 and 27c" ae1027 27c6a
Generating /path/to/foo/versions/53fffde5ad5_merge_ae1_and_27c.py ... done
known as "branch at" syntax; this syntax allows us to state that we want to
use a specific revision, let's say a "head" revision, in terms of a *specific*
branch. While normally, we can't refer to ``alembic upgrade head`` when
-there's multiple heads, we *can* refer to this head specifcally using
+there's multiple heads, we *can* refer to this head specifically using
``shoppingcart@head`` syntax::
$ alembic upgrade shoppingcart@head
What we see is that the full history of the ``networking`` branch, in terms
of an "upgrade" to the "head", will include that the tree building
up ``55af2cb1c267, add another account column``
-will be pulled in first. Interstingly, we don't see this displayed
+will be pulled in first. Interestingly, we don't see this displayed
when we display history in the other direction, e.g. from ``networking@base``::
$ alembic history -r networking@base:
:tags: bug, operations
:tickets: 1300
- Added support for ``op.drop_constraint()`` to support PostrgreSQL
+ Added support for ``op.drop_constraint()`` to support PostgreSQL
``ExcludeConstraint`` objects, as well as other constraint-like objects
that may be present in third party dialects, by resolving the ``type_``
parameter to be ``None`` for this case. Autogenerate has also been
.. change::
- :tags: bug, commmands
+ :tags: bug, commands
:tickets: 1299
Fixed issue where the ``revision_environment`` directive in ``alembic.ini``
internally; instead, the state variables of each operation object will be
used to produce the corresponding construct when the operation is invoked.
The rationale is so that environments which make use of
- operation-manipulation schemes such as those those discussed in
+ operation-manipulation schemes such as those discussed in
:ref:`autogen_rewriter` are better supported, allowing end-user code to
manipulate the public attributes of these objects which will then be
expressed in the final output, an example is
unconditionally erase the version table before stamping anything. This is
useful for development where non-existent version identifiers might be left
within the table. Additionally, ``alembic.stamp`` now supports a list of
- revision identifiers, which are intended to allow setting up muliple heads
+ revision identifiers, which are intended to allow setting up multiple heads
at once. Overall handling of version identifiers within the
``alembic.stamp`` command has been improved with many new tests and
use cases added.
unconditionally, as in the vast majority of cases the server default is to
be CURRENT_TIMESTAMP which may also be potentially bundled with an "ON
UPDATE CURRENT_TIMESTAMP" directive, which SQLAlchemy does not currently
- support as a distinct field. The fix addiionally improves the server
+ support as a distinct field. The fix additionally improves the server
default comparison logic when the "ON UPDATE" clause is present and
there are parenthesis to be adjusted for as is the case on some MariaDB
versions.
in SQLAlchemy 1.1. When the source column indicates autoincrement
as True or "auto", the flag will render as True if the original column
contextually indicates that it should have "autoincrement" keywords,
- and when the source column explcitly sets it to False, this is also
+ and when the source column explicitly sets it to False, this is also
rendered. The behavior is intended to preserve the AUTO_INCREMENT flag
on MySQL as the column is fully recreated on this backend. Note that this
flag does **not** support alteration of a column's "autoincrement" status,
Added a rule for Postgresql to not render a "drop unique" and "drop index"
given the same name; for now it is assumed that the "index" is the
- implicit one Postgreql generates. Future integration with
+ implicit one PostgreSQL generates. Future integration with
new SQLAlchemy 1.0 features will improve this to be more
resilient.
:tickets: 93
Added :meth:`.Operations.create_primary_key`
- operation, will genenerate an ADD CONSTRAINT
+ operation, will generate an ADD CONSTRAINT
for a primary key.
.. change::
If we need to add a new column to a view, for example, we have to drop
it entirely and recreate it fresh with the extra column added, referring to
the whole structure; but to make it even tougher, if we wish to support
-downgrade operarations in our migration scripts,
+downgrade operations in our migration scripts,
we need to refer to the *previous* version of that
construct fully, and we'd much rather not have to type out the whole
definition in multiple places.
part of the SQLAlchemy_ project.
User issues, discussion of potential bugs and features are most easily
-discussed using `Github Discussions <https://github.com/sqlalchemy/alembic/discussions/>`_.
+discussed using `GitHub Discussions <https://github.com/sqlalchemy/alembic/discussions/>`_.
.. _bugs:
)
There's a solution to all this naming work, which is to use an **automated
-naming convention**. For some years, SQLAlchemy has encourgaged the use of
+naming convention**. For some years, SQLAlchemy has encouraged the use of
DDL Events in order to create naming schemes. The :meth:`~sqlalchemy.events.DDLEvents.after_parent_attach`
event in particular is the best place to intercept when :class:`~sqlalchemy.schema.Constraint`
and :class:`~sqlalchemy.schema.Index` objects are being associated with a parent
# ### end Alembic commands ###""", # noqa,
)
- def test_imports_maintined(self):
+ def test_imports_maintained(self):
template_args = {}
self.context.opts["render_as_batch"] = True
__only_on__ = "postgresql"
__backend__ = True
- def test_uses_explcit_schema_in_default_one(self):
+ def test_uses_explicit_schema_in_default_one(self):
default_schema = self.bind.dialect.default_schema_name
m1 = MetaData()
diffs = self._fixture(m1, m2, include_schemas=True)
eq_(diffs, [])
- def test_uses_explcit_schema_in_default_two(self):
+ def test_uses_explicit_schema_in_default_two(self):
default_schema = self.bind.dialect.default_schema_name
m1 = MetaData()
eq_(diffs[0][1].schema, "test_schema")
eq_(diffs[0][1].c.keys(), ["y"])
- def test_uses_explcit_schema_in_default_three(self):
+ def test_uses_explicit_schema_in_default_three(self):
default_schema = self.bind.dialect.default_schema_name
m1 = MetaData()
def test_render_add_column_system(self):
# this would never actually happen since "system" columns
- # can't be added in any case. Howver it will render as
+ # can't be added in any case. However it will render as
# part of op.CreateTableOp.
op_obj = ops.AddColumnOp("foo", Column("xmin", Integer, system=True))
eq_ignore_whitespace(
@config.requirements.computed_columns_api
@testing.combinations((True,), (False,))
- def test_render_alter_column_computed_modify_default_perisisted(
+ def test_render_alter_column_computed_modify_default_persisted(
self, persisted
):
op_obj = ops.AlterColumnOp(
@config.requirements.computed_columns_api
@testing.combinations((True,), (False,))
- def test_render_alter_column_computed_existing_default_perisisted(
+ def test_render_alter_column_computed_existing_default_persisted(
self, persisted
):
c = sa.Computed("42", persisted=persisted)
new_table = self._assert_impl(
impl,
colnames=["id", "email", "user_id"],
- ddl_not_contains="CONSTRANT fk1",
+ ddl_not_contains="CONSTRAINT ufk",
)
eq_(list(new_table.foreign_keys), [])
cfg.attributes["connection"] = m1
eq_(cfg.attributes["connection"], m1)
- def test_attributes_construtor(self):
+ def test_attributes_constructor(self):
m1 = mock.Mock()
m2 = mock.Mock()
cfg = config.Config(attributes={"m1": m1})
As of #803 the constructs try to behave more intelligently
about the state they were given, so that they can both "reverse"
- themselves but also take into accout their current state.
+ themselves but also take into account their current state.
"""
def teardown_class(cls):
clear_staging_env()
- def test_begin_comit(self):
+ def test_begin_commit(self):
with capture_context_buffer(transactional_ddl=True) as buf:
command.upgrade(self.cfg, self.a, sql=True)
assert "SET TRANSACTION READ WRITE\n\n/" in buf.getvalue()
def test_compare_unicode_literal(self):
self._compare_default_roundtrip(String(), "im a default")
- # TOOD: will need to actually eval() the repr() and
+ # TODO: will need to actually eval() the repr() and
# spend more effort figuring out exactly the kind of expression
# to use
def _TODO_test_compare_character_str_w_singlequote(self):
([], self.c2.revision, self.e.revision),
)
- def test_stamp_labled_head_across_merge_from_multiple_branch(self):
+ def test_stamp_labeled_head_across_merge_from_multiple_branch(self):
# this is testing that filter_for_lineage() checks for
# d1 both in terms of "c2branch" as well as that the "head"
# revision "f" is the head of both d1 and d2
projects / thirdparty / sqlalchemy / alembic.git / commitdiff
