From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 11 Sep 2023 17:43:22 +0000 (-0400) Subject: Spelling fixes (#1310) X-Git-Tag: rel_1_12_1~11 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8542a09459daa9a75a73ab8e4c109686255e4f34;p=thirdparty%2Fsqlalchemy%2Falembic.git Spelling fixes (#1310) Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> Co-authored-by: Federico Caselli --- diff --git a/README.rst b/README.rst index 59c83715..478a7ba0 100644 --- a/README.rst +++ b/README.rst @@ -65,7 +65,7 @@ The goals of Alembic are: * 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 diff --git a/alembic/config.py b/alembic/config.py index 41e941b3..55b5811a 100644 --- a/alembic/config.py +++ b/alembic/config.py @@ -34,7 +34,7 @@ class Config: 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:: diff --git a/alembic/op.pyi b/alembic/op.pyi index 2bb16d81..d2721d82 100644 --- a/alembic/op.pyi +++ b/alembic/op.pyi @@ -197,7 +197,7 @@ def alter_column( 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. @@ -1080,7 +1080,7 @@ def execute( ) 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:: diff --git a/alembic/operations/base.py b/alembic/operations/base.py index 8b74dfd7..6a279ee6 100644 --- a/alembic/operations/base.py +++ b/alembic/operations/base.py @@ -723,7 +723,7 @@ class Operations(AbstractOperations): 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. @@ -1489,7 +1489,7 @@ class Operations(AbstractOperations): ) 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:: diff --git a/alembic/operations/ops.py b/alembic/operations/ops.py index 5f0b5632..bef6e81f 100644 --- a/alembic/operations/ops.py +++ b/alembic/operations/ops.py @@ -1882,7 +1882,7 @@ class AlterColumnOp(AlterTableOp): 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. @@ -2490,7 +2490,7 @@ class ExecuteSQLOp(MigrateOperation): ) 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:: diff --git a/alembic/script/revision.py b/alembic/script/revision.py index 6c18e7ae..aa0e9040 100644 --- a/alembic/script/revision.py +++ b/alembic/script/revision.py @@ -1090,13 +1090,13 @@ class RevisionMap: ) -> 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. """ @@ -1139,7 +1139,7 @@ class RevisionMap: 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) @@ -1206,7 +1206,7 @@ class RevisionMap: ) -> 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 diff --git a/docs/build/branches.rst b/docs/build/branches.rst index 0eed96d1..4b74ca0b 100644 --- a/docs/build/branches.rst +++ b/docs/build/branches.rst @@ -4,7 +4,7 @@ Working with Branches ===================== 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 @@ -117,7 +117,7 @@ turn it into a "diamond" structure:: 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 @@ -392,7 +392,7 @@ However, when using branch labels, we usually want to use them using a syntax 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 @@ -707,7 +707,7 @@ are descendants:: 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: diff --git a/docs/build/changelog.rst b/docs/build/changelog.rst index b72f33f7..4c8024c5 100644 --- a/docs/build/changelog.rst +++ b/docs/build/changelog.rst @@ -15,7 +15,7 @@ Changelog :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 @@ -25,7 +25,7 @@ Changelog .. change:: - :tags: bug, commmands + :tags: bug, commands :tickets: 1299 Fixed issue where the ``revision_environment`` directive in ``alembic.ini`` @@ -1072,7 +1072,7 @@ Changelog 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 @@ -1849,7 +1849,7 @@ Changelog 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. @@ -2114,7 +2114,7 @@ Changelog 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. @@ -2778,7 +2778,7 @@ Changelog 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, @@ -3900,7 +3900,7 @@ Changelog 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. @@ -4784,7 +4784,7 @@ Changelog :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:: diff --git a/docs/build/cookbook.rst b/docs/build/cookbook.rst index 0b59de97..510699a3 100644 --- a/docs/build/cookbook.rst +++ b/docs/build/cookbook.rst @@ -275,7 +275,7 @@ changes to them, we have to refer to the whole definition at once. 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. diff --git a/docs/build/front.rst b/docs/build/front.rst index 9ec8b7df..2dba5b95 100644 --- a/docs/build/front.rst +++ b/docs/build/front.rst @@ -120,7 +120,7 @@ Alembic is developed by `Mike Bayer `_, and is part of the SQLAlchemy_ project. User issues, discussion of potential bugs and features are most easily -discussed using `Github Discussions `_. +discussed using `GitHub Discussions `_. .. _bugs: diff --git a/docs/build/naming.rst b/docs/build/naming.rst index 43837482..55ccbde5 100644 --- a/docs/build/naming.rst +++ b/docs/build/naming.rst @@ -118,7 +118,7 @@ of ``unique=True`` and type out the whole constraint:: ) 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 diff --git a/tests/test_autogen_composition.py b/tests/test_autogen_composition.py index aac0c346..b4b5bf33 100644 --- a/tests/test_autogen_composition.py +++ b/tests/test_autogen_composition.py @@ -227,7 +227,7 @@ nullable=True)) # ### end Alembic commands ###""", # noqa, ) - def test_imports_maintined(self): + def test_imports_maintained(self): template_args = {} self.context.opts["render_as_batch"] = True diff --git a/tests/test_autogen_diffs.py b/tests/test_autogen_diffs.py index d03771ee..8a2cf996 100644 --- a/tests/test_autogen_diffs.py +++ b/tests/test_autogen_diffs.py @@ -237,7 +237,7 @@ class AutogenDefaultSchemaTest(AutogenFixtureTest, TestBase): __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() @@ -249,7 +249,7 @@ class AutogenDefaultSchemaTest(AutogenFixtureTest, TestBase): 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() @@ -265,7 +265,7 @@ class AutogenDefaultSchemaTest(AutogenFixtureTest, TestBase): 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() diff --git a/tests/test_autogen_render.py b/tests/test_autogen_render.py index b00fdc1f..5c200b1f 100644 --- a/tests/test_autogen_render.py +++ b/tests/test_autogen_render.py @@ -1094,7 +1094,7 @@ class AutogenRenderTest(TestBase): 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( @@ -2121,7 +2121,7 @@ class AutogenRenderTest(TestBase): @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( @@ -2137,7 +2137,7 @@ class AutogenRenderTest(TestBase): @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) diff --git a/tests/test_batch.py b/tests/test_batch.py index dd1c0089..9992af2c 100644 --- a/tests/test_batch.py +++ b/tests/test_batch.py @@ -794,7 +794,7 @@ class BatchApplyTest(TestBase): 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), []) diff --git a/tests/test_config.py b/tests/test_config.py index 9f3929a7..73ce2aa9 100644 --- a/tests/test_config.py +++ b/tests/test_config.py @@ -102,7 +102,7 @@ class ConfigTest(TestBase): 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}) diff --git a/tests/test_op.py b/tests/test_op.py index 403a94aa..67d41947 100644 --- a/tests/test_op.py +++ b/tests/test_op.py @@ -1305,7 +1305,7 @@ class ObjectFromToTest(TestBase): 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. """ diff --git a/tests/test_oracle.py b/tests/test_oracle.py index 3b6ddcac..83e03948 100644 --- a/tests/test_oracle.py +++ b/tests/test_oracle.py @@ -35,7 +35,7 @@ class FullEnvironmentTests(TestBase): 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() diff --git a/tests/test_postgresql.py b/tests/test_postgresql.py index 4b328e55..9a62c4f2 100644 --- a/tests/test_postgresql.py +++ b/tests/test_postgresql.py @@ -797,7 +797,7 @@ class PostgresqlDefaultCompareTest(TestBase): 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): diff --git a/tests/test_version_traversal.py b/tests/test_version_traversal.py index e1504b9c..0628f3fd 100644 --- a/tests/test_version_traversal.py +++ b/tests/test_version_traversal.py @@ -1331,7 +1331,7 @@ class MergedPathTest(MigrationTest): ([], 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