diff options
| author | Ville Skyttä <ville.skytta@iki.fi> | 2016-05-03 22:47:23 +0300 |
|---|---|---|
| committer | Ville Skyttä <ville.skytta@iki.fi> | 2016-05-03 22:47:23 +0300 |
| commit | 49d12142b37dc5ec117a00849f92a503506a08ab (patch) | |
| tree | 28e6e60ba36ae89c209b03359565690d5add3204 | |
| parent | bde46e33593805584c7c0dedb3a666909fb67888 (diff) | |
| download | sqlalchemy-49d12142b37dc5ec117a00849f92a503506a08ab.tar.gz | |
Spelling fixespr/266
75 files changed, 185 insertions, 185 deletions
diff --git a/README.rst b/README.rst index 376b5bc50..024c1f146 100644 --- a/README.rst +++ b/README.rst @@ -103,7 +103,7 @@ SQLAlchemy's philosophy: commit() is called. SQLAlchemy encourages applications to create a consistent means of delineating the start and end of a series of operations. -* Never render a literal value in a SQL statement. +* Never render a literal value in an SQL statement. Bound parameters are used to the greatest degree possible, allowing query optimizers to cache query plans effectively and making SQL injection diff --git a/README.unittests.rst b/README.unittests.rst index 5aeba51f6..d82ac8e18 100644 --- a/README.unittests.rst +++ b/README.unittests.rst @@ -192,7 +192,7 @@ except SQLite and Firebird. The names are:: Please refer to your vendor documentation for the proper syntax to create these namespaces - the database user must have permission to create and drop -tables within these schemas. Its perfectly fine to run the test suite +tables within these schemas. It's perfectly fine to run the test suite without these namespaces present, it only means that a handful of tests which expect them to be present will fail. diff --git a/doc/build/changelog/changelog_04.rst b/doc/build/changelog/changelog_04.rst index 1bd49871c..f0bef1c3a 100644 --- a/doc/build/changelog/changelog_04.rst +++ b/doc/build/changelog/changelog_04.rst @@ -765,7 +765,7 @@ The case() function now also takes a dictionary as its whens parameter. It also interprets the "THEN" expressions as values by default, meaning case([(x==y, - "foo")]) will interpret "foo" as a bound value, not a SQL + "foo")]) will interpret "foo" as a bound value, not an SQL expression. use text(expr) for literal SQL expressions in this case. For the criterion itself, these may be literal strings only if the "value" keyword is present, otherwise @@ -2785,7 +2785,7 @@ :tickets: 818 removed __len__ from "dynamic" collection as it would require issuing - a SQL "count()" operation, thus forcing all list evaluations to issue + an SQL "count()" operation, thus forcing all list evaluations to issue redundant SQL .. change:: @@ -3182,7 +3182,7 @@ during an executemany()-style call. inline=True flag on any insert/update statement also forces the same behavior with a single execute(). result.postfetch_cols() is a collection of columns for which the previous - single insert or update statement contained a SQL-side default expression. + single insert or update statement contained an SQL-side default expression. .. change:: :tags: diff --git a/doc/build/changelog/changelog_05.rst b/doc/build/changelog/changelog_05.rst index 04ab11dca..fd6fbeaec 100644 --- a/doc/build/changelog/changelog_05.rst +++ b/doc/build/changelog/changelog_05.rst @@ -3519,7 +3519,7 @@ makes SQLA's SQLite date type compatible with datetimes that were saved directly using Pysqlite (which just calls str()). Note that this is incompatible with the existing microseconds - values in a SQLA 0.4 generated SQLite database file. + values in an SQLA 0.4 generated SQLite database file. To get the old behavior globally: diff --git a/doc/build/changelog/changelog_06.rst b/doc/build/changelog/changelog_06.rst index 927aae21d..e19aae0ba 100644 --- a/doc/build/changelog/changelog_06.rst +++ b/doc/build/changelog/changelog_06.rst @@ -426,7 +426,7 @@ :tags: orm :tickets: 1995 - Fixed bug where a column with a SQL or server side default + Fixed bug where a column with an SQL or server side default that was excluded from a mapping with include_properties or exclude_properties would result in UnmappedColumnError. @@ -3460,7 +3460,7 @@ The type/expression system now does a more complete job of determining the return type from an expression as well as the adaptation of the Python operator into - a SQL operator, based on the full left/right/operator + an SQL operator, based on the full left/right/operator of the given expression. In particular the date/time/interval system created for Postgresql EXTRACT in has now been generalized into diff --git a/doc/build/changelog/changelog_07.rst b/doc/build/changelog/changelog_07.rst index fa952f012..a775de5ad 100644 --- a/doc/build/changelog/changelog_07.rst +++ b/doc/build/changelog/changelog_07.rst @@ -526,7 +526,7 @@ :tickets: 2568 Adjusted a very old bugfix which attempted - to work around a SQLite issue that itself was + to work around an SQLite issue that itself was "fixed" as of sqlite 3.6.14, regarding quotes surrounding a table name when using the "foreign_key_list" pragma. The fix has been @@ -923,7 +923,7 @@ :tickets: 2467 Fixed bug whereby if cast() is used - on a SQL expression whose type is not supported + on an SQL expression whose type is not supported by cast() and therefore CAST isn't rendered by the dialect, the order of evaluation could change if the casted expression required that it be @@ -4265,7 +4265,7 @@ :tags: orm :tickets: 2018 - the aliased() function, if passed a SQL FromClause element + the aliased() function, if passed an SQL FromClause element (i.e. not a mapped class), will return element.alias() instead of raising an error on AliasedClass. @@ -4405,7 +4405,7 @@ :tags: orm :tickets: 1995 - Fixed bug where a column with a SQL or server side default + Fixed bug where a column with an SQL or server side default that was excluded from a mapping with include_properties or exclude_properties would result in UnmappedColumnError. (also in 0.6.7) diff --git a/doc/build/changelog/changelog_08.rst b/doc/build/changelog/changelog_08.rst index 5d74af71c..7c694c8a6 100644 --- a/doc/build/changelog/changelog_08.rst +++ b/doc/build/changelog/changelog_08.rst @@ -2101,7 +2101,7 @@ It was the "aliasing" behavior of the latter use case that was getting in the way of the former use case. The method now - specifically considers a SQL expression like + specifically considers an SQL expression like :func:`.expression.select` or :func:`.expression.alias` separately from a mapped entity like a :func:`.aliased` construct. diff --git a/doc/build/changelog/changelog_09.rst b/doc/build/changelog/changelog_09.rst index 3ac0ab0b4..e629eef23 100644 --- a/doc/build/changelog/changelog_09.rst +++ b/doc/build/changelog/changelog_09.rst @@ -771,7 +771,7 @@ :tickets: 3159 Fixed bug where Postgresql JSON type was not able to persist or - otherwise render a SQL NULL column value, rather than a JSON-encoded + otherwise render an SQL NULL column value, rather than a JSON-encoded ``'null'``. To support this case, changes are as follows: * The value :func:`.null` can now be specified, which will always @@ -875,7 +875,7 @@ :tickets: 3130 :versions: 1.0.0b1 - Fixed a SQLite join rewriting issue where a subquery that is embedded + Fixed an SQLite join rewriting issue where a subquery that is embedded as a scalar subquery such as within an IN would receive inappropriate substitutions from the enclosing query, if the same table were present inside the subquery as were in the enclosing query such as in a diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 07188b771..8c366e4b6 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -583,7 +583,7 @@ Fixed two issues regarding Sybase reflection, allowing tables without primary keys to be reflected as well as ensured that - a SQL statement involved in foreign key detection is pre-fetched up + an SQL statement involved in foreign key detection is pre-fetched up front to avoid driver issues upon nested queries. Fixes here courtesy Eugene Zapolsky; note that we cannot currently test Sybase to locally verify these changes. @@ -1142,8 +1142,8 @@ :tickets: 3402 Fixed regression within the flush process when an attribute were - set to a SQL expression for an UPDATE, and the SQL expression when - compared to the previous value of the attribute would produce a SQL + set to an SQL expression for an UPDATE, and the SQL expression when + compared to the previous value of the attribute would produce an SQL comparison other than ``==`` or ``!=``, the exception "Boolean value of this clause is not defined" would raise. The fix ensures that the unit of work will not interpret the SQL expression in this way. @@ -1329,7 +1329,7 @@ there's no data being referenced). In order to maintain the new feature of :ticket:`3282` while still - allowing a SQLite DROP operation to maintain ordering, we now + allowing an SQLite DROP operation to maintain ordering, we now do the sort with full FKs taken under consideration, and if we encounter an unresolvable cycle, only *then* do we forego attempting to sort the tables; we instead emit a warning and go with the unsorted list. @@ -1943,7 +1943,7 @@ :pullreq: github:150 The type of expression is reported when an object passed to a - SQL expression unit can't be interpreted as a SQL fragment; + SQL expression unit can't be interpreted as an SQL fragment; pull request courtesy Ryan P. Kelly. .. change:: diff --git a/doc/build/changelog/migration_08.rst b/doc/build/changelog/migration_08.rst index fd153a925..d72b2e11d 100644 --- a/doc/build/changelog/migration_08.rst +++ b/doc/build/changelog/migration_08.rst @@ -734,7 +734,7 @@ functionality, except on the database side:: Column('data', LowerString) ) -Above, the ``LowerString`` type defines a SQL expression that will be emitted +Above, the ``LowerString`` type defines an SQL expression that will be emitted whenever the ``test_table.c.data`` column is rendered in the columns clause of a SELECT statement:: diff --git a/doc/build/changelog/migration_10.rst b/doc/build/changelog/migration_10.rst index a4fbf117d..8064b242d 100644 --- a/doc/build/changelog/migration_10.rst +++ b/doc/build/changelog/migration_10.rst @@ -601,7 +601,7 @@ to not support this behavior; third party dialects may also need modification in order to take advantage of the new behavior. A dialect which currently uses the ``._limit`` or ``._offset`` attributes will continue to function for those cases where the limit/offset was specified as a simple integer value. -However, when a SQL expression is specified, these two attributes will +However, when an SQL expression is specified, these two attributes will instead raise a :class:`.CompileError` on access. A third-party dialect which wishes to support the new feature should now call upon the ``._limit_clause`` and ``._offset_clause`` attributes to receive the full SQL expression, rather @@ -634,7 +634,7 @@ does not support ALTER, in the case that during a DROP, the given tables have an unresolvable cycle; in this case a warning is emitted, and the tables are dropped with **no** ordering, which is usually fine on SQLite unless constraints are enabled. To resolve the warning and proceed with at least -a partial ordering on a SQLite database, particuarly one where constraints +a partial ordering on an SQLite database, particuarly one where constraints are enabled, re-apply "use_alter" flags to those :class:`.ForeignKey` and :class:`.ForeignKeyConstraint` objects which should be explicitly omitted from the sort. @@ -862,7 +862,7 @@ Column server defaults now render literal values The "literal binds" compiler flag is switched on when a :class:`.DefaultClause`, set up by :paramref:`.Column.server_default` -is present as a SQL expression to be compiled. This allows literals +is present as an SQL expression to be compiled. This allows literals embedded in SQL to render correctly, such as:: from sqlalchemy import Table, Column, MetaData, Text @@ -1841,7 +1841,7 @@ full SQL string to :meth:`.Connection.execute`, but that you can send strings with SQL expressions into many functions, such as :meth:`.Select.where`, :meth:`.Query.filter`, and :meth:`.Select.order_by`. -Note that by "SQL expressions" we mean a **full fragment of a SQL string**, +Note that by "SQL expressions" we mean a **full fragment of an SQL string**, such as:: # the argument sent to where() is a full SQL expression diff --git a/doc/build/changelog/migration_11.rst b/doc/build/changelog/migration_11.rst index 6f0da3780..cb028cc6e 100644 --- a/doc/build/changelog/migration_11.rst +++ b/doc/build/changelog/migration_11.rst @@ -185,7 +185,7 @@ as :class:`.NullType` is used to refer to any expression of unknown type. Additionally, the treatment of a so-called "unhashable" type is slightly -different than its been in previous releases; internally we are using +different than it's been in previous releases; internally we are using the ``id()`` function to get a "hash value" from these structures, just as we would any ordinary mapped object. This replaces the previous approach which applied a counter to the object. @@ -212,11 +212,11 @@ string value:: >>> some_user = User() >>> q = s.query(User).filter(User.name == some_user) ... - sqlalchemy.exc.ArgumentError: Object <__main__.User object at 0x103167e90> is not legal as a SQL literal value + sqlalchemy.exc.ArgumentError: Object <__main__.User object at 0x103167e90> is not legal as an SQL literal value The exception is now immediate when the comparison is made between ``User.name == some_user``. Previously, a comparison like the above -would produce a SQL expression that would only fail once resolved +would produce an SQL expression that would only fail once resolved into a DBAPI execution call; the mapped ``User`` object would ultimately become a bound parameter that would be rejected by the DBAPI. @@ -1239,7 +1239,7 @@ this CHECK constraint can now be disabled using the new Large parameter and row values are now truncated in logging and exception displays ---------------------------------------------------------------------------------- -A large value present as a bound parameter for a SQL statement, as well as a +A large value present as a bound parameter for an SQL statement, as well as a large value present in a result row, will now be truncated during display within logging, exception reporting, as well as ``repr()`` of the row itself:: @@ -1364,7 +1364,7 @@ JSON "null" is inserted as expected with ORM operations, regardless of column de The :class:`.types.JSON` type and its descendant types :class:`.postgresql.JSON` and :class:`.mysql.JSON` have a flag :paramref:`.types.JSON.none_as_null` which when set to True indicates that the Python value ``None`` should translate -into a SQL NULL rather than a JSON NULL value. This flag defaults to False, +into an SQL NULL rather than a JSON NULL value. This flag defaults to False, which means that the column should *never* insert SQL NULL or fall back to a default unless the :func:`.null` constant were used. However, this would fail in the ORM under two circumstances; one is when the column also contained @@ -1415,7 +1415,7 @@ New JSON.NULL Constant Added To ensure that an application can always have full control at the value level of whether a :class:`.types.JSON`, :class:`.postgresql.JSON`, :class:`.mysql.JSON`, or :class:`.postgresql.JSONB` column -should receive a SQL NULL or JSON ``"null"`` value, the constant +should receive an SQL NULL or JSON ``"null"`` value, the constant :attr:`.types.JSON.NULL` has been added, which in conjunction with :func:`.null` can be used to determine fully between SQL NULL and JSON ``"null"``, regardless of what :paramref:`.types.JSON.none_as_null` is set @@ -1697,7 +1697,7 @@ Above, in the :paramref:`.relationship.primaryjoin` expression, we are using :func:`.type_coerce` to handle bound parameters passed via lazyloading as integers, since we already know these will come from our ``StringAsInt`` type which maintains the value as an integer in -Python. We are then using :func:`.cast` so that as a SQL expression, +Python. We are then using :func:`.cast` so that as an SQL expression, the VARCHAR "id" column will be CAST to an integer for a regular non- converted join as with :meth:`.Query.join` or :func:`.orm.joinedload`. That is, a joinedload of ``.pets`` looks like:: @@ -1839,7 +1839,7 @@ This includes: * The SQL type assigned to indexed access of an :class:`~.postgresql.ARRAY` takes into account the number of dimensions configured. An :class:`~.postgresql.ARRAY` with three - dimensions will return a SQL expression with a type of :class:`~.postgresql.ARRAY` of + dimensions will return an SQL expression with a type of :class:`~.postgresql.ARRAY` of one less dimension. Given a column with type ``ARRAY(Integer, dimensions=3)``, we can now perform this expression:: diff --git a/doc/build/core/connections.rst b/doc/build/core/connections.rst index 709642ecf..adcbcf049 100644 --- a/doc/build/core/connections.rst +++ b/doc/build/core/connections.rst @@ -7,7 +7,7 @@ Working with Engines and Connections .. module:: sqlalchemy.engine This section details direct usage of the :class:`.Engine`, -:class:`.Connection`, and related objects. Its important to note that when +:class:`.Connection`, and related objects. It's important to note that when using the SQLAlchemy ORM, these objects are not generally accessed; instead, the :class:`.Session` object is used as the interface to the database. However, for applications that are built around direct usage of textual SQL @@ -295,7 +295,7 @@ Explicit, connectionless execution delivers the expression to the Implicit execution is also connectionless, and makes usage of the :meth:`~.Executable.execute` method on the expression itself. This method is provided as part of the -:class:`.Executable` class, which refers to a SQL statement that is sufficient +:class:`.Executable` class, which refers to an SQL statement that is sufficient for being invoked against the database. The method makes usage of the assumption that either an :class:`~sqlalchemy.engine.Engine` or diff --git a/doc/build/core/defaults.rst b/doc/build/core/defaults.rst index a7287a360..ab1506834 100644 --- a/doc/build/core/defaults.rst +++ b/doc/build/core/defaults.rst @@ -321,7 +321,7 @@ use case, add the flag ``optional=True`` to the provides no other option for generating primary key identifiers. The :class:`~sqlalchemy.schema.Sequence` object also has the ability to be -executed standalone like a SQL expression, which has the effect of calling its +executed standalone like an SQL expression, which has the effect of calling its "next value" function:: seq = Sequence('some_sequence') diff --git a/doc/build/core/engines.rst b/doc/build/core/engines.rst index 17ec9416c..a6950c949 100644 --- a/doc/build/core/engines.rst +++ b/doc/build/core/engines.rst @@ -160,7 +160,7 @@ And for an absolute file path, the three slashes are followed by the absolute pa #Windows alternative using raw string engine = create_engine(r'sqlite:///C:\path\to\foo.db') -To use a SQLite ``:memory:`` database, specify an empty URL:: +To use an SQLite ``:memory:`` database, specify an empty URL:: engine = create_engine('sqlite://') diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst index 0fd78abeb..fef3c9f2e 100644 --- a/doc/build/core/tutorial.rst +++ b/doc/build/core/tutorial.rst @@ -248,7 +248,7 @@ Executing The interesting part of an :class:`~sqlalchemy.sql.expression.Insert` is executing it. In this tutorial, we will generally focus on the most explicit -method of executing a SQL construct, and later touch upon some "shortcut" ways +method of executing an SQL construct, and later touch upon some "shortcut" ways to do it. The ``engine`` object we created is a repository for database connections capable of issuing SQL to the database. To acquire a connection, we use the ``connect()`` method:: @@ -552,7 +552,7 @@ some of its capabilities. We've seen how to equate two columns to each other: >>> print(users.c.id == addresses.c.user_id) users.id = addresses.user_id -If we use a literal value (a literal meaning, not a SQLAlchemy clause object), +If we use a literal value (a literal meaning, not an SQLAlchemy clause object), we get a bind parameter: .. sourcecode:: pycon+sql @@ -569,7 +569,7 @@ we did with the :class:`~sqlalchemy.sql.expression.Insert` object to see it: >>> (users.c.id == 7).compile().params {u'id_1': 7} -Most Python operators, as it turns out, produce a SQL expression here, like +Most Python operators, as it turns out, produce an SQL expression here, like equals, not equals, etc.: .. sourcecode:: pycon+sql diff --git a/doc/build/faq/connections.rst b/doc/build/faq/connections.rst index 658b4f785..01aeb2bea 100644 --- a/doc/build/faq/connections.rst +++ b/doc/build/faq/connections.rst @@ -94,10 +94,10 @@ a COMMIT as any connection is returned to the pool:: engine = create_engine('mssql://scott:tiger@mydsn', pool=QueuePool(reset_on_return='commit')) -I am using multiple connections with a SQLite database (typically to test transaction operation), and my test program is not working! +I am using multiple connections with an SQLite database (typically to test transaction operation), and my test program is not working! ---------------------------------------------------------------------------------------------------------------------------------------------------------- -If using a SQLite ``:memory:`` database, or a version of SQLAlchemy prior +If using an SQLite ``:memory:`` database, or a version of SQLAlchemy prior to version 0.7, the default connection pool is the :class:`.SingletonThreadPool`, which maintains exactly one SQLite connection per thread. So two connections in use in the same thread will actually be the same SQLite diff --git a/doc/build/faq/ormconfiguration.rst b/doc/build/faq/ormconfiguration.rst index 3a2ea29a6..03f8370de 100644 --- a/doc/build/faq/ormconfiguration.rst +++ b/doc/build/faq/ormconfiguration.rst @@ -244,7 +244,7 @@ all queries. The consequence of this is that any query that limits rows using ``LIMIT`` or ``OFFSET`` should **always** specify an ``ORDER BY``. Otherwise, it is not deterministic which rows will actually be returned. -When we use a SQLAlchemy method like :meth:`.Query.first`, we are in fact +When we use an SQLAlchemy method like :meth:`.Query.first`, we are in fact applying a ``LIMIT`` of one to the query, so without an explicit ordering it is not deterministic what row we actually get back. While we may not notice this for simple queries on databases that usually @@ -293,7 +293,7 @@ the two queries may not see the same results: ORDER BY anon_1.users_id Depending on database specifics, there is -a chance we may get the a result like the following for the two queries:: +a chance we may get a result like the following for the two queries:: -- query #1 +--------+ diff --git a/doc/build/faq/performance.rst b/doc/build/faq/performance.rst index 8413cb5a2..6ea0a0616 100644 --- a/doc/build/faq/performance.rst +++ b/doc/build/faq/performance.rst @@ -10,8 +10,8 @@ Performance .. _faq_how_to_profile: -How can I profile a SQLAlchemy powered application? ---------------------------------------------------- +How can I profile an SQLAlchemy powered application? +---------------------------------------------------- Looking for performance issues typically involves two stratgies. One is query profiling, and the other is code profiling. @@ -22,7 +22,7 @@ Query Profiling Sometimes just plain SQL logging (enabled via python's logging module or via the ``echo=True`` argument on :func:`.create_engine`) can give an idea how long things are taking. For example, if you log something -right after a SQL operation, you'd see something like this in your +right after an SQL operation, you'd see something like this in your log:: 17:37:48,325 INFO [sqlalchemy.engine.base.Engine.0x...048c] SELECT ... diff --git a/doc/build/faq/sessions.rst b/doc/build/faq/sessions.rst index 8a47db77a..f7818018a 100644 --- a/doc/build/faq/sessions.rst +++ b/doc/build/faq/sessions.rst @@ -171,7 +171,7 @@ But why isn't the one automatic call to ROLLBACK enough? Why must I ROLLBACK ag ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is again a matter of the :class:`.Session` providing a consistent interface and -refusing to guess about what context its being used. For example, the +refusing to guess about what context it's being used in. For example, the :class:`.Session` supports "framing" above within multiple levels. Such as, suppose you had a decorator ``@with_session()``, which did this:: @@ -227,7 +227,7 @@ comes into play if you want to SAVEPOINT- you might call ``begin_nested()`` several times, and the ``commit()``/``rollback()`` calls each resolve the most recent ``begin_nested()``. The meaning of ``rollback()`` or ``commit()`` is dependent upon which enclosing block it is called, and you might have any -sequence of ``rollback()``/``commit()`` in any order, and its the level of nesting +sequence of ``rollback()``/``commit()`` in any order, and it's the level of nesting that determines their behavior. In both of the above cases, if ``flush()`` broke the nesting of transaction @@ -275,7 +275,7 @@ Query has no ``__len__()``, why not? The Python ``__len__()`` magic method applied to an object allows the ``len()`` builtin to be used to determine the length of the collection. It's intuitive -that a SQL query object would link ``__len__()`` to the :meth:`.Query.count` +that an SQL query object would link ``__len__()`` to the :meth:`.Query.count` method, which emits a `SELECT COUNT`. The reason this is not possible is because evaluating the query as a list would incur two SQL calls instead of one:: diff --git a/doc/build/faq/sqlexpressions.rst b/doc/build/faq/sqlexpressions.rst index c3504218b..0d1733c7e 100644 --- a/doc/build/faq/sqlexpressions.rst +++ b/doc/build/faq/sqlexpressions.rst @@ -11,7 +11,7 @@ SQL Expressions How do I render SQL expressions as strings, possibly with bound parameters inlined? ------------------------------------------------------------------------------------ -The "stringification" of a SQLAlchemy statement or Query in the vast majority +The "stringification" of an SQLAlchemy statement or Query in the vast majority of cases is as simple as:: print(str(statement)) diff --git a/doc/build/glossary.rst b/doc/build/glossary.rst index 4fd9b0633..ac7d683e9 100644 --- a/doc/build/glossary.rst +++ b/doc/build/glossary.rst @@ -58,7 +58,7 @@ Glossary of :class:`.InstrumentedAttribute`, which are descriptors that provide the above mentioned ``__get__()``, ``__set__()`` and ``__delete__()`` methods. The :class:`.InstrumentedAttribute` - will generate a SQL expression when used at the class level:: + will generate an SQL expression when used at the class level:: >>> print MyClass.data == 5 data = :data_1 @@ -628,7 +628,7 @@ Glossary The relationship from ``department`` to ``employee`` is one to many, since many employee records can be associated with a - single department. A SQLAlchemy mapping might look like:: + single department. An SQLAlchemy mapping might look like:: class Department(Base): __tablename__ = 'department' @@ -679,7 +679,7 @@ Glossary The relationship from ``employee`` to ``department`` is many to one, since many employee records can be associated with a - single department. A SQLAlchemy mapping might look like:: + single department. An SQLAlchemy mapping might look like:: class Department(Base): __tablename__ = 'department' @@ -873,7 +873,7 @@ Glossary FOREIGN KEY project_id REFERENCES project(id) ) - A SQLAlchemy declarative mapping for the above might look like:: + An SQLAlchemy declarative mapping for the above might look like:: class Employee(Base): __tablename__ = 'employee' diff --git a/doc/build/orm/extensions/baked.rst b/doc/build/orm/extensions/baked.rst index 83cee51da..4515067c8 100644 --- a/doc/build/orm/extensions/baked.rst +++ b/doc/build/orm/extensions/baked.rst @@ -10,7 +10,7 @@ Baked Queries construction and string-compilation steps. This means that for a particular :class:`~.query.Query` building scenario that is used more than once, all of the Python function invocation involved in building the query -from its initial construction up through generating a SQL string will only +from its initial construction up through generating an SQL string will only occur **once**, rather than for each time that query is built up and executed. The rationale for this system is to greatly reduce Python interpreter @@ -155,7 +155,7 @@ as being impacted by this particular form of overhead. .. topic:: Measure twice, cut once - For background on how to profile a SQLAlchemy application, please see + For background on how to profile an SQLAlchemy application, please see the section :ref:`faq_performance`. It is essential that performance measurement techniques are used when attempting to improve the performance of an application. diff --git a/doc/build/orm/extensions/declarative/relationships.rst b/doc/build/orm/extensions/declarative/relationships.rst index fb53c28bb..fc9dc114f 100644 --- a/doc/build/orm/extensions/declarative/relationships.rst +++ b/doc/build/orm/extensions/declarative/relationships.rst @@ -130,7 +130,7 @@ as well, passing the string name of the table as defined in the id = Column(Integer, primary_key=True) keywords = relationship("Keyword", secondary="keywords") -As with traditional mapping, its generally not a good idea to use +As with traditional mapping, it's generally not a good idea to use a :class:`.Table` as the "secondary" argument which is also mapped to a class, unless the :func:`.relationship` is declared with ``viewonly=True``. Otherwise, the unit-of-work system may attempt duplicate INSERT and diff --git a/doc/build/orm/loading_relationships.rst b/doc/build/orm/loading_relationships.rst index 3a0026bbe..aa993c359 100644 --- a/doc/build/orm/loading_relationships.rst +++ b/doc/build/orm/loading_relationships.rst @@ -15,7 +15,7 @@ Using Loader Strategies: Lazy Loading, Eager Loading By default, all inter-object relationships are **lazy loading**. The scalar or collection attribute associated with a :func:`~sqlalchemy.orm.relationship` contains a trigger which fires the first time the attribute is accessed. This -trigger, in all but one case, issues a SQL call at the point of access +trigger, in all but one case, issues an SQL call at the point of access in order to load the related object or objects: .. sourcecode:: python+sql diff --git a/doc/build/orm/mapped_attributes.rst b/doc/build/orm/mapped_attributes.rst index 2e7e9b3eb..260041ebc 100644 --- a/doc/build/orm/mapped_attributes.rst +++ b/doc/build/orm/mapped_attributes.rst @@ -156,7 +156,7 @@ usable with :class:`.Query`. To provide these, we instead use the self._email = email The ``.email`` attribute, in addition to providing getter/setter behavior when we have an -instance of ``EmailAddress``, also provides a SQL expression when used at the class level, +instance of ``EmailAddress``, also provides an SQL expression when used at the class level, that is, from the ``EmailAddress`` class directly: .. sourcecode:: python+sql @@ -210,7 +210,7 @@ logic:: @email.expression def email(cls): - """Produce a SQL expression that represents the value + """Produce an SQL expression that represents the value of the _email column, minus the last twelve characters.""" return func.substr(cls._email, 0, func.length(cls._email) - 12) @@ -218,7 +218,7 @@ logic:: Above, accessing the ``email`` property of an instance of ``EmailAddress`` will return the value of the ``_email`` attribute, removing or adding the hostname ``@example.com`` from the value. When we query against the ``email`` -attribute, a SQL function is rendered which produces the same effect: +attribute, an SQL function is rendered which produces the same effect: .. sourcecode:: python+sql diff --git a/doc/build/orm/mapped_sql_expr.rst b/doc/build/orm/mapped_sql_expr.rst index e091e33a6..63595440b 100644 --- a/doc/build/orm/mapped_sql_expr.rst +++ b/doc/build/orm/mapped_sql_expr.rst @@ -75,7 +75,7 @@ needs to be present inside the hybrid, using the ``if`` statement in Python and Using column_property --------------------- -The :func:`.orm.column_property` function can be used to map a SQL +The :func:`.orm.column_property` function can be used to map an SQL expression in a manner similar to a regularly mapped :class:`.Column`. With this technique, the attribute is loaded along with all other column-mapped attributes at load time. This is in some @@ -176,7 +176,7 @@ here with a classical mapping:: Using a plain descriptor ------------------------- -In cases where a SQL query more elaborate than what :func:`.orm.column_property` +In cases where an SQL query more elaborate than what :func:`.orm.column_property` or :class:`.hybrid_property` can provide must be emitted, a regular Python function accessed as an attribute can be used, assuming the expression only needs to be available on an already-loaded instance. The function @@ -204,5 +204,5 @@ which is then used to emit a query:: The plain descriptor approach is useful as a last resort, but is less performant in the usual case than both the hybrid and column property approaches, in that -it needs to emit a SQL query upon each access. +it needs to emit an SQL query upon each access. diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst index a30d486b5..f679c5c15 100644 --- a/doc/build/orm/persistence_techniques.rst +++ b/doc/build/orm/persistence_techniques.rst @@ -7,7 +7,7 @@ Additional Persistence Techniques Embedding SQL Insert/Update Expressions into a Flush ===================================================== -This feature allows the value of a database column to be set to a SQL +This feature allows the value of a database column to be set to an SQL expression instead of a literal value. It's especially useful for atomic updates, calling stored procedures, etc. All you do is assign an expression to an attribute:: @@ -18,7 +18,7 @@ an attribute:: someobject = session.query(SomeClass).get(5) - # set 'value' attribute to a SQL expression adding one + # set 'value' attribute to an SQL expression adding one someobject.value = some_table.c.value + 1 # issues "UPDATE some_table SET value=value+1" @@ -48,7 +48,7 @@ This is most easily accomplished using the # execute a string statement result = session.execute("select * from table where id=:id", {'id':7}) - # execute a SQL expression construct + # execute an SQL expression construct result = session.execute(select([mytable]).where(mytable.c.id==7)) The current :class:`~sqlalchemy.engine.Connection` held by the diff --git a/doc/build/orm/session_basics.rst b/doc/build/orm/session_basics.rst index 0f96ba50a..2fbb5082f 100644 --- a/doc/build/orm/session_basics.rst +++ b/doc/build/orm/session_basics.rst @@ -681,7 +681,7 @@ initiated by calling the :meth:`~.Session.begin` method. construct within the :class:`.Session` itself which may be maintaining zero or more actual database (DBAPI) transactions. An individual DBAPI connection begins participation in the "transaction" as it is first - used to execute a SQL statement, then remains present until the session-level + used to execute an SQL statement, then remains present until the session-level "transaction" is completed. See :ref:`unitofwork_transaction` for further detail. diff --git a/doc/build/orm/session_state_management.rst b/doc/build/orm/session_state_management.rst index 090bf7674..1a4a879c9 100644 --- a/doc/build/orm/session_state_management.rst +++ b/doc/build/orm/session_state_management.rst @@ -416,7 +416,7 @@ Refreshing / Expiring :term:`Expiring` means that the database-persisted data held inside a series of object attributes is erased, in such a way that when those attributes -are next accessed, a SQL query is emitted which will refresh that data from +are next accessed, an SQL query is emitted which will refresh that data from the database. When we talk about expiration of data we are usually talking about an object @@ -599,7 +599,7 @@ may have occurred. can't fully predict when the same SELECT statement, emitted a second time, will definitely return the data we already have, or will return new data. So as a best guess, it assumes that within the scope of a transaction, unless - it is known that a SQL expression has been emitted to modify a particular row, + it is known that an SQL expression has been emitted to modify a particular row, there's no need to refresh a row unless explicitly told to do so. The :meth:`.Session.expire` and :meth:`.Session.refresh` methods are used in diff --git a/doc/build/orm/tutorial.rst b/doc/build/orm/tutorial.rst index 0a9fc7430..cd5536b7a 100644 --- a/doc/build/orm/tutorial.rst +++ b/doc/build/orm/tutorial.rst @@ -148,7 +148,7 @@ is described in detail at :ref:`declarative_mixins`. When our class is constructed, Declarative replaces all the :class:`.Column` objects with special Python accessors known as :term:`descriptors`; this is a process known as :term:`instrumentation`. The "instrumented" mapped class -will provide us with the means to refer to our table in a SQL context as well +will provide us with the means to refer to our table in an SQL context as well as to persist and load the values of columns from the database. Outside of what the mapping process does to our class, the class remains @@ -1429,7 +1429,7 @@ get rows back for those users who don't have any addresses, e.g.:: ON users.id=adr_count.user_id Using the :class:`~sqlalchemy.orm.query.Query`, we build a statement like this -from the inside out. The ``statement`` accessor returns a SQL expression +from the inside out. The ``statement`` accessor returns an SQL expression representing the statement generated by a particular :class:`~sqlalchemy.orm.query.Query` - this is an instance of a :func:`~.expression.select` construct, which are described in :ref:`sqlexpression_toplevel`:: @@ -1440,7 +1440,7 @@ construct, which are described in :ref:`sqlexpression_toplevel`:: ... group_by(Address.user_id).subquery() The ``func`` keyword generates SQL functions, and the ``subquery()`` method on -:class:`~sqlalchemy.orm.query.Query` produces a SQL expression construct +:class:`~sqlalchemy.orm.query.Query` produces an SQL expression construct representing a SELECT statement embedded within an alias (it's actually shorthand for ``query.statement.alias()``). diff --git a/examples/dogpile_caching/advanced.py b/examples/dogpile_caching/advanced.py index feccaa3ba..be9898762 100644 --- a/examples/dogpile_caching/advanced.py +++ b/examples/dogpile_caching/advanced.py @@ -18,7 +18,7 @@ def load_name_range(start, end, invalidate=False): The cache option we set up is called "name_range", indicating a range of names for the Person class. - The `Person.addresses` collections are also cached. Its basically + The `Person.addresses` collections are also cached. It's basically another level of tuning here, as that particular cache option can be transparently replaced with joinedload(Person.addresses). The effect is that each Person and their Address collection diff --git a/examples/dogpile_caching/caching_query.py b/examples/dogpile_caching/caching_query.py index 9ac0d431a..c636c5261 100644 --- a/examples/dogpile_caching/caching_query.py +++ b/examples/dogpile_caching/caching_query.py @@ -202,7 +202,7 @@ class RelationshipCache(MapperOption): def process_query_conditionally(self, query): """Process a Query that is used within a lazy loader. - (the process_query_conditionally() method is a SQLAlchemy + (the process_query_conditionally() method is an SQLAlchemy hook invoked only within lazyload.) """ diff --git a/lib/sqlalchemy/dialects/mssql/base.py b/lib/sqlalchemy/dialects/mssql/base.py index 051efa719..2f94d61ea 100644 --- a/lib/sqlalchemy/dialects/mssql/base.py +++ b/lib/sqlalchemy/dialects/mssql/base.py @@ -425,7 +425,7 @@ Compatibility Levels -------------------- MSSQL supports the notion of setting compatibility levels at the database level. This allows, for instance, to run a database that -is compatible with SQL2000 while running on a SQL2005 database +is compatible with SQL2000 while running on an SQL2005 database server. ``server_version_info`` will always return the database server version information (in this case SQL2005) and not the compatibility level information. Because of this, if running under diff --git a/lib/sqlalchemy/dialects/postgresql/base.py b/lib/sqlalchemy/dialects/postgresql/base.py index eb3449e40..6c1909e1d 100644 --- a/lib/sqlalchemy/dialects/postgresql/base.py +++ b/lib/sqlalchemy/dialects/postgresql/base.py @@ -901,7 +901,7 @@ class ENUM(sqltypes.Enum): or :meth:`~.postgresql.ENUM.drop` are called directly. Setting to ``False`` is helpful - when invoking a creation scheme to a SQL file + when invoking a creation scheme to an SQL file without access to the actual database - the :meth:`~.postgresql.ENUM.create` and :meth:`~.postgresql.ENUM.drop` methods can diff --git a/lib/sqlalchemy/dialects/postgresql/hstore.py b/lib/sqlalchemy/dialects/postgresql/hstore.py index 67923fe39..ca8cffcd2 100644 --- a/lib/sqlalchemy/dialects/postgresql/hstore.py +++ b/lib/sqlalchemy/dialects/postgresql/hstore.py @@ -137,7 +137,7 @@ class HSTORE(sqltypes.Indexable, sqltypes.Concatenable, sqltypes.TypeEngine): def has_key(self, other): """Boolean expression. Test for presence of a key. Note that the - key may be a SQLA expression. + key may be an SQLA expression. """ return self.operate(HAS_KEY, other, result_type=sqltypes.Boolean) @@ -169,13 +169,13 @@ class HSTORE(sqltypes.Indexable, sqltypes.Concatenable, sqltypes.TypeEngine): def defined(self, key): """Boolean expression. Test for presence of a non-NULL value for - the key. Note that the key may be a SQLA expression. + the key. Note that the key may be an SQLA expression. """ return _HStoreDefinedFunction(self.expr, key) def delete(self, key): """HStore expression. Returns the contents of this hstore with the - given key deleted. Note that the key may be a SQLA expression. + given key deleted. Note that the key may be an SQLA expression. """ if isinstance(key, dict): key = _serialize_hstore(key) @@ -246,7 +246,7 @@ ischema_names['hstore'] = HSTORE class hstore(sqlfunc.GenericFunction): - """Construct an hstore value within a SQL expression using the + """Construct an hstore value within an SQL expression using the Postgresql ``hstore()`` function. The :class:`.hstore` function accepts one or two arguments as described diff --git a/lib/sqlalchemy/dialects/postgresql/json.py b/lib/sqlalchemy/dialects/postgresql/json.py index b0f0f7cf0..1791b49d5 100644 --- a/lib/sqlalchemy/dialects/postgresql/json.py +++ b/lib/sqlalchemy/dialects/postgresql/json.py @@ -242,7 +242,7 @@ class JSONB(JSON): def has_key(self, other): """Boolean expression. Test for presence of a key. Note that the - key may be a SQLA expression. + key may be an SQLA expression. """ return self.operate(HAS_KEY, other, result_type=sqltypes.Boolean) diff --git a/lib/sqlalchemy/dialects/postgresql/psycopg2.py b/lib/sqlalchemy/dialects/postgresql/psycopg2.py index fe245b21d..046aa22a8 100644 --- a/lib/sqlalchemy/dialects/postgresql/psycopg2.py +++ b/lib/sqlalchemy/dialects/postgresql/psycopg2.py @@ -188,7 +188,7 @@ one of these characters in its name. One is to specify the ) Above, an INSERT statement such as ``measurement.insert()`` will use -``size_meters`` as the parameter name, and a SQL expression such as +``size_meters`` as the parameter name, and an SQL expression such as ``measurement.c.size_meters > 10`` will derive the bound parameter name from the ``size_meters`` key as well. diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py index ddd869448..63f2d896f 100644 --- a/lib/sqlalchemy/dialects/sqlite/base.py +++ b/lib/sqlalchemy/dialects/sqlite/base.py @@ -16,7 +16,7 @@ Date and Time Types SQLite does not have built-in DATE, TIME, or DATETIME types, and pysqlite does not provide out of the box functionality for translating values between Python -`datetime` objects and a SQLite-supported format. SQLAlchemy's own +`datetime` objects and an SQLite-supported format. SQLAlchemy's own :class:`~sqlalchemy.types.DateTime` and related types provide date formatting and parsing functionality when SQlite is used. The implementation classes are :class:`~.sqlite.DATETIME`, :class:`~.sqlite.DATE` and :class:`~.sqlite.TIME`. @@ -153,7 +153,7 @@ with an error. This behavior becomes more critical when used in conjunction with the SQLAlchemy ORM. SQLAlchemy's :class:`.Session` object by default runs within a transaction, and with its autoflush model, may emit DML preceding -any SELECT statement. This may lead to a SQLite database that locks +any SELECT statement. This may lead to an SQLite database that locks more quickly than is expected. The locking mode of SQLite and the pysqlite driver can be manipulated to some degree, however it should be noted that achieving a high degree of write-concurrency with SQLite is a losing battle. diff --git a/lib/sqlalchemy/dialects/sqlite/pysqlite.py b/lib/sqlalchemy/dialects/sqlite/pysqlite.py index 33d04deeb..9db4cebdf 100644 --- a/lib/sqlalchemy/dialects/sqlite/pysqlite.py +++ b/lib/sqlalchemy/dialects/sqlite/pysqlite.py @@ -37,7 +37,7 @@ Connect Strings --------------- The file specification for the SQLite database is taken as the "database" -portion of the URL. Note that the format of a SQLAlchemy url is:: +portion of the URL. Note that the format of an SQLAlchemy url is:: driver://user:pass@host/database diff --git a/lib/sqlalchemy/engine/base.py b/lib/sqlalchemy/engine/base.py index 859819a34..646f26497 100644 --- a/lib/sqlalchemy/engine/base.py +++ b/lib/sqlalchemy/engine/base.py @@ -365,7 +365,7 @@ class Connection(Connectable): actual level on the underlying DBAPI connection regardless of how this state was set. Compare to the :attr:`.Connection.default_isolation_level` accessor - which returns the dialect-level setting without performing a SQL + which returns the dialect-level setting without performing an SQL query. .. versionadded:: 0.9.9 @@ -877,7 +877,7 @@ class Connection(Connectable): return self.execute(object, *multiparams, **params).scalar() def execute(self, object, *multiparams, **params): - """Executes the a SQL statement construct and returns a + """Executes the SQL statement construct and returns a :class:`.ResultProxy`. :param object: The statement to be executed. May be diff --git a/lib/sqlalchemy/engine/interfaces.py b/lib/sqlalchemy/engine/interfaces.py index 26731f9a5..45f73a407 100644 --- a/lib/sqlalchemy/engine/interfaces.py +++ b/lib/sqlalchemy/engine/interfaces.py @@ -197,7 +197,7 @@ class Dialect(object): Allows dialects to configure options based on server version info or other properties. - The connection passed here is a SQLAlchemy Connection object, + The connection passed here is an SQLAlchemy Connection object, with full capabilities. The initialize() method of the base dialect should be called via diff --git a/lib/sqlalchemy/engine/result.py b/lib/sqlalchemy/engine/result.py index 0333d9ec2..d13c8590b 100644 --- a/lib/sqlalchemy/engine/result.py +++ b/lib/sqlalchemy/engine/result.py @@ -742,7 +742,7 @@ class ResultProxy(object): This is a DBAPI specific method and is only functional for those backends which support it, for statements - where it is appropriate. It's behavior is not + where it is appropriate. Its behavior is not consistent across backends. Usage of this method is normally unnecessary when diff --git a/lib/sqlalchemy/events.py b/lib/sqlalchemy/events.py index c679db37d..2247cf996 100644 --- a/lib/sqlalchemy/events.py +++ b/lib/sqlalchemy/events.py @@ -697,7 +697,7 @@ class ConnectionEvents(event.Events): closing the cursor, rolling back of the transaction in the case of connectionless execution, and disposing of the entire connection pool if a "disconnect" was detected. The - exception is then wrapped in a SQLAlchemy DBAPI exception + exception is then wrapped in an SQLAlchemy DBAPI exception wrapper and re-thrown. :param conn: :class:`.Connection` object diff --git a/lib/sqlalchemy/exc.py b/lib/sqlalchemy/exc.py index 272984229..f9e9ae53f 100644 --- a/lib/sqlalchemy/exc.py +++ b/lib/sqlalchemy/exc.py @@ -198,7 +198,7 @@ UnmappedColumnError = None class StatementError(SQLAlchemyError): - """An error occurred during execution of a SQL statement. + """An error occurred during execution of an SQL statement. :class:`StatementError` wraps the exception raised during execution, and features :attr:`.statement` @@ -265,7 +265,7 @@ class DBAPIError(StatementError): and :attr:`~.StatementError.params` attributes which supply context regarding the specifics of the statement which had an issue, for the typical case when the error was raised within the context of - emitting a SQL statement. + emitting an SQL statement. The wrapped exception object is available in the :attr:`~.StatementError.orig` attribute. Its type and properties are diff --git a/lib/sqlalchemy/ext/associationproxy.py b/lib/sqlalchemy/ext/associationproxy.py index fdc44f386..832680382 100644 --- a/lib/sqlalchemy/ext/associationproxy.py +++ b/lib/sqlalchemy/ext/associationproxy.py @@ -483,7 +483,7 @@ class _AssociationCollection(object): lazy_collection A callable returning a list-based collection of entities (usually an - object attribute managed by a SQLAlchemy relationship()) + object attribute managed by an SQLAlchemy relationship()) creator A function that creates new target entities. Given one parameter: diff --git a/lib/sqlalchemy/ext/compiler.py b/lib/sqlalchemy/ext/compiler.py index 86156be1f..417979927 100644 --- a/lib/sqlalchemy/ext/compiler.py +++ b/lib/sqlalchemy/ext/compiler.py @@ -115,7 +115,7 @@ SQL and DDL constructs are each compiled using different base compilers - ``SQLCompiler`` and ``DDLCompiler``. A common need is to access the compilation rules of SQL expressions from within a DDL expression. The ``DDLCompiler`` includes an accessor ``sql_compiler`` for this reason, such as -below where we generate a CHECK constraint that embeds a SQL expression:: +below where we generate a CHECK constraint that embeds an SQL expression:: @compiles(MyConstraint) def compile_my_constraint(constraint, ddlcompiler, **kw): @@ -252,7 +252,7 @@ A synopsis is as follows: type = TIMESTAMP() * :class:`~sqlalchemy.sql.functions.FunctionElement` - This is a hybrid of a - ``ColumnElement`` and a "from clause" like object, and represents a SQL + ``ColumnElement`` and a "from clause" like object, and represents an SQL function or stored procedure type of call. Since most databases support statements along the line of "SELECT FROM <some function>" ``FunctionElement`` adds in the ability to be used in the FROM clause of a diff --git a/lib/sqlalchemy/ext/horizontal_shard.py b/lib/sqlalchemy/ext/horizontal_shard.py index 996e81fca..b625a2539 100644 --- a/lib/sqlalchemy/ext/horizontal_shard.py +++ b/lib/sqlalchemy/ext/horizontal_shard.py @@ -80,7 +80,7 @@ class ShardedSession(Session): """Construct a ShardedSession. :param shard_chooser: A callable which, passed a Mapper, a mapped - instance, and possibly a SQL clause, returns a shard ID. This id + instance, and possibly an SQL clause, returns a shard ID. This id may be based off of the attributes present within the object, or on some round-robin scheme. If the scheme is based on a selection, it should set whatever state on the instance to mark it in the future as diff --git a/lib/sqlalchemy/ext/hybrid.py b/lib/sqlalchemy/ext/hybrid.py index bbf386742..077df2c02 100644 --- a/lib/sqlalchemy/ext/hybrid.py +++ b/lib/sqlalchemy/ext/hybrid.py @@ -124,7 +124,7 @@ Defining Expression Behavior Distinct from Attribute Behavior Our usage of the ``&`` and ``|`` bitwise operators above was fortunate, considering our functions operated on two boolean values to return a new one. In many cases, the construction of an in-Python -function and a SQLAlchemy SQL expression have enough differences that +function and an SQLAlchemy SQL expression have enough differences that two separate Python expressions should be defined. The :mod:`~sqlalchemy.ext.hybrid` decorators define the :meth:`.hybrid_property.expression` modifier for this purpose. As an @@ -416,7 +416,7 @@ previous ``CaseInsensitiveComparator`` class with a new "Label to apply to Query tuple results" Above, the ``CaseInsensitiveWord`` object represents ``self.word``, -which may be a SQL function, or may be a Python native. By +which may be an SQL function, or may be a Python native. By overriding ``operate()`` and ``__clause_element__()`` to work in terms of ``self.word``, all comparison operations will work against the "converted" form of ``word``, whether it be SQL side or Python side. @@ -765,7 +765,7 @@ class hybrid_property(interfaces.InspectionAttrInfo): return self def expression(self, expr): - """Provide a modifying decorator that defines a SQL-expression + """Provide a modifying decorator that defines an SQL-expression producing method.""" self.expr = expr diff --git a/lib/sqlalchemy/ext/mutable.py b/lib/sqlalchemy/ext/mutable.py index 571bbbda3..258dc4ecf 100644 --- a/lib/sqlalchemy/ext/mutable.py +++ b/lib/sqlalchemy/ext/mutable.py @@ -46,7 +46,7 @@ with any type whose target Python type may be mutable, including :class:`.PickleType`, :class:`.postgresql.ARRAY`, etc. When using the :mod:`sqlalchemy.ext.mutable` extension, the value itself -tracks all parents which reference it. Below, we illustrate the a simple +tracks all parents which reference it. Below, we illustrate a simple version of the :class:`.MutableDict` dictionary object, which applies the :class:`.Mutable` mixin to a plain Python dictionary:: @@ -551,7 +551,7 @@ class Mutable(MutableBase): @classmethod def as_mutable(cls, sqltype): - """Associate a SQL type with this mutable Python type. + """Associate an SQL type with this mutable Python type. This establishes listeners that will detect ORM mappings against the given type, adding mutation event trackers to those mappings. @@ -596,7 +596,7 @@ class Mutable(MutableBase): class MutableComposite(MutableBase): """Mixin that defines transparent propagation of change - events on a SQLAlchemy "composite" object to its + events on an SQLAlchemy "composite" object to its owning parent or parents. See the example in :ref:`mutable_composites` for usage information. diff --git a/lib/sqlalchemy/interfaces.py b/lib/sqlalchemy/interfaces.py index 464ad9f70..b72a15141 100644 --- a/lib/sqlalchemy/interfaces.py +++ b/lib/sqlalchemy/interfaces.py @@ -96,7 +96,7 @@ class PoolListener(object): """Called once for each new DB-API connection or Pool's ``creator()``. dbapi_con - A newly connected raw DB-API connection (not a SQLAlchemy + A newly connected raw DB-API connection (not an SQLAlchemy ``Connection`` wrapper). con_record @@ -108,7 +108,7 @@ class PoolListener(object): """Called exactly once for the first DB-API connection. dbapi_con - A newly connected raw DB-API connection (not a SQLAlchemy + A newly connected raw DB-API connection (not an SQLAlchemy ``Connection`` wrapper). con_record diff --git a/lib/sqlalchemy/orm/descriptor_props.py b/lib/sqlalchemy/orm/descriptor_props.py index 6c87ef9ba..316ef4df4 100644 --- a/lib/sqlalchemy/orm/descriptor_props.py +++ b/lib/sqlalchemy/orm/descriptor_props.py @@ -628,7 +628,7 @@ class ComparableProperty(DescriptorProperty): the :mod:`~sqlalchemy.ext.hybrid` extension. See the example at :ref:`hybrid_custom_comparators`. - Allows any Python descriptor to behave like a SQL-enabled + Allows any Python descriptor to behave like an SQL-enabled attribute when used at the class level in queries, allowing redefinition of expression operator behavior. diff --git a/lib/sqlalchemy/orm/interfaces.py b/lib/sqlalchemy/orm/interfaces.py index faab70e37..8a024b683 100644 --- a/lib/sqlalchemy/orm/interfaces.py +++ b/lib/sqlalchemy/orm/interfaces.py @@ -109,7 +109,7 @@ class MapperProperty(_MappedAttribute, InspectionAttr, util.MemoizedSlots): return {} def setup(self, context, entity, path, adapter, **kwargs): - """Called by Query for the purposes of constructing a SQL statement. + """Called by Query for the purposes of constructing an SQL statement. Each MapperProperty associated with the target mapper processes the statement referenced by the query context, adding columns and/or diff --git a/lib/sqlalchemy/orm/mapper.py b/lib/sqlalchemy/orm/mapper.py index 2236b2f76..23be6556d 100644 --- a/lib/sqlalchemy/orm/mapper.py +++ b/lib/sqlalchemy/orm/mapper.py @@ -266,7 +266,7 @@ class Mapper(InspectionAttr): :ref:`inheritance_toplevel` - :param inherit_condition: For joined table inheritance, a SQL + :param inherit_condition: For joined table inheritance, an SQL expression which will define how the two tables are joined; defaults to a natural join between the two tables. @@ -396,7 +396,7 @@ class Mapper(InspectionAttr): } It may also be specified - as a SQL expression, as in this example where we + as an SQL expression, as in this example where we use the :func:`.case` construct to provide a conditional approach:: @@ -436,7 +436,7 @@ class Mapper(InspectionAttr): } .. versionchanged:: 0.7.4 - ``polymorphic_on`` may be specified as a SQL expression, + ``polymorphic_on`` may be specified as an SQL expression, or refer to any attribute configured with :func:`.column_property`, or to the string name of one. diff --git a/lib/sqlalchemy/orm/properties.py b/lib/sqlalchemy/orm/properties.py index f3dce7541..d4fc03160 100644 --- a/lib/sqlalchemy/orm/properties.py +++ b/lib/sqlalchemy/orm/properties.py @@ -88,7 +88,7 @@ class ColumnProperty(StrategizedProperty): :param expire_on_flush=True: Disable expiry on flush. A column_property() which refers - to a SQL expression (and not a single table-bound column) + to an SQL expression (and not a single table-bound column) is considered to be a "read only" property; populating it has no effect on the state of data, and it can only return database state. For this reason a column_property()'s value diff --git a/lib/sqlalchemy/orm/query.py b/lib/sqlalchemy/orm/query.py index 4606c2ffb..11cdc58f2 100644 --- a/lib/sqlalchemy/orm/query.py +++ b/lib/sqlalchemy/orm/query.py @@ -650,7 +650,7 @@ class Query(object): """A readonly attribute which returns the current WHERE criterion for this Query. - This returned value is a SQL expression construct, or ``None`` if no + This returned value is an SQL expression construct, or ``None`` if no criterion has been established. """ @@ -1688,7 +1688,7 @@ class Query(object): ) def join(self, *props, **kwargs): - """Create a SQL JOIN against this :class:`.Query` object's criterion + """Create an SQL JOIN against this :class:`.Query` object's criterion and apply generatively, returning the newly resulting :class:`.Query`. **Simple Relationship Joins** diff --git a/lib/sqlalchemy/orm/relationships.py b/lib/sqlalchemy/orm/relationships.py index 17f94d4af..46f6a8131 100644 --- a/lib/sqlalchemy/orm/relationships.py +++ b/lib/sqlalchemy/orm/relationships.py @@ -438,7 +438,7 @@ class RelationshipProperty(StrategizedProperty): construct a non-standard join condition, which makes use of columns or expressions that do not normally refer to their "parent" column, such as a join condition expressed by a - complex comparison using a SQL function. + complex comparison using an SQL function. The :func:`.relationship` construct will raise informative error messages that suggest the use of the @@ -672,7 +672,7 @@ class RelationshipProperty(StrategizedProperty): :ref:`post_update` - Introductory documentation and examples. :param primaryjoin: - a SQL expression that will be used as the primary + an SQL expression that will be used as the primary join of this child object against the parent object, or in a many-to-many relationship the join of the primary object to the association table. By default, this value is computed based on the @@ -727,7 +727,7 @@ class RelationshipProperty(StrategizedProperty): relationship loaders. :param secondaryjoin: - a SQL expression that will be used as the join of + an SQL expression that will be used as the join of an association table to the child object. By default, this value is computed based on the foreign key relationships of the association and child tables. diff --git a/lib/sqlalchemy/orm/session.py b/lib/sqlalchemy/orm/session.py index 1cf1bdb24..7a99a0e75 100644 --- a/lib/sqlalchemy/orm/session.py +++ b/lib/sqlalchemy/orm/session.py @@ -913,7 +913,7 @@ class Session(_SessionClassMethods): return conn def execute(self, clause, params=None, mapper=None, bind=None, **kw): - """Execute a SQL expression construct or string statement within + """Execute an SQL expression construct or string statement within the current transaction. Returns a :class:`.ResultProxy` representing @@ -2443,7 +2443,7 @@ class Session(_SessionClassMethods): cases, the attribute is assumed to have a change, even if there is ultimately no net change against its database value. SQLAlchemy in most cases does not need the "old" value when a set event occurs, so - it skips the expense of a SQL call if the old value isn't present, + it skips the expense of an SQL call if the old value isn't present, based on the assumption that an UPDATE of the scalar value is usually needed, and in those few cases where it isn't, is less expensive on average than issuing a defensive SELECT. diff --git a/lib/sqlalchemy/orm/strategies.py b/lib/sqlalchemy/orm/strategies.py index 370cb974b..27afe2a98 100644 --- a/lib/sqlalchemy/orm/strategies.py +++ b/lib/sqlalchemy/orm/strategies.py @@ -100,7 +100,7 @@ def _register_attribute( @properties.ColumnProperty.strategy_for(instrument=False, deferred=False) class UninstrumentedColumnLoader(LoaderStrategy): - """Represent the a non-instrumented MapperProperty. + """Represent a non-instrumented MapperProperty. The polymorphic_on argument of mapper() often results in this, if the argument is against the with_polymorphic selectable. diff --git a/lib/sqlalchemy/orm/util.py b/lib/sqlalchemy/orm/util.py index f76be0380..d7c21c726 100644 --- a/lib/sqlalchemy/orm/util.py +++ b/lib/sqlalchemy/orm/util.py @@ -895,7 +895,7 @@ def join( left and right selectables may be not only core selectable objects such as :class:`.Table`, but also mapped classes or :class:`.AliasedClass` instances. The "on" clause can - be a SQL expression, or an attribute or string name + be an SQL expression, or an attribute or string name referencing a configured :func:`.relationship`. :func:`.orm.join` is not commonly needed in modern usage, diff --git a/lib/sqlalchemy/pool.py b/lib/sqlalchemy/pool.py index 4bd8f60ec..a781ac8a9 100644 --- a/lib/sqlalchemy/pool.py +++ b/lib/sqlalchemy/pool.py @@ -906,7 +906,7 @@ class SingletonThreadPool(Pool): :class:`.SingletonThreadPool` may be improved in a future release, however in its current status it is generally used only for test - scenarios using a SQLite ``:memory:`` database and is not recommended + scenarios using an SQLite ``:memory:`` database and is not recommended for production use. diff --git a/lib/sqlalchemy/sql/crud.py b/lib/sqlalchemy/sql/crud.py index 70e03d220..960d1c09a 100644 --- a/lib/sqlalchemy/sql/crud.py +++ b/lib/sqlalchemy/sql/crud.py @@ -343,7 +343,7 @@ def _append_param_insert_pk_returning(compiler, stmt, c, values, kw): If the column has a Python-side default, we will create a bound parameter for it and "pre-execute" the Python function. If - the column has a SQL expression default, or is a sequence, + the column has an SQL expression default, or is a sequence, we will add it directly into the INSERT statement and add a RETURNING element to get the new value. If the column has a server side default or is marked as the "autoincrement" column, diff --git a/lib/sqlalchemy/sql/dml.py b/lib/sqlalchemy/sql/dml.py index 8f368dcdb..601c36619 100644 --- a/lib/sqlalchemy/sql/dml.py +++ b/lib/sqlalchemy/sql/dml.py @@ -643,7 +643,7 @@ class Update(ValuesBase): For databases which support this, an ``UPDATE FROM`` clause will be generated, or on MySQL, a multi-table update. The statement will fail on databases that don't have support for multi-table - update statements. A SQL-standard method of referring to + update statements. An SQL-standard method of referring to additional tables in the WHERE clause is to use a correlated subquery:: @@ -705,7 +705,7 @@ class Update(ValuesBase): The values referred to in ``values`` are typically: * a literal data value (i.e. string, number, etc.) - * a SQL expression, such as a related :class:`.Column`, + * an SQL expression, such as a related :class:`.Column`, a scalar-returning :func:`.select` construct, etc. diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py index 00c2c37ba..90b80853a 100644 --- a/lib/sqlalchemy/sql/elements.py +++ b/lib/sqlalchemy/sql/elements.py @@ -198,7 +198,7 @@ class ClauseElement(Visitable): """return the 'constructor' for this ClauseElement. This is for the purposes for creating a new object of - this type. Usually, its just the element's __class__. + this type. Usually, it's just the element's __class__. However, the "Annotated" version of the object overrides to return the class of its proxied element. @@ -494,7 +494,7 @@ class ColumnElement(operators.ColumnOperators, ClauseElement): While the most familiar kind of :class:`.ColumnElement` is the :class:`.Column` object, :class:`.ColumnElement` serves as the basis - for any unit that may be present in a SQL expression, including + for any unit that may be present in an SQL expression, including the expressions themselves, SQL functions, bound parameters, literal expressions, keywords such as ``NULL``, etc. :class:`.ColumnElement` is the ultimate base class for all such elements. @@ -865,7 +865,7 @@ class BindParameter(ColumnElement): The return value is an instance of :class:`.BindParameter`; this is a :class:`.ColumnElement` subclass which represents a so-called - "placeholder" value in a SQL expression, the value of which is + "placeholder" value in an SQL expression, the value of which is supplied at the point at which the statement in executed against a database connection. @@ -874,7 +874,7 @@ class BindParameter(ColumnElement): used at expression time. In this way, it serves not just as a "placeholder" for eventual population, but also as a means of representing so-called "unsafe" values which should not be rendered - directly in a SQL statement, but rather should be passed along + directly in an SQL statement, but rather should be passed along to the :term:`DBAPI` as values which need to be correctly escaped and potentially handled for type-safety. @@ -1034,7 +1034,7 @@ class BindParameter(ColumnElement): :param quote: True if this parameter name requires quoting and is not - currently known as a SQLAlchemy reserved word; this currently + currently known as an SQLAlchemy reserved word; this currently only applies to the Oracle backend, where bound names must sometimes be quoted. @@ -1161,7 +1161,7 @@ class BindParameter(ColumnElement): class TypeClause(ClauseElement): - """Handle a type keyword in a SQL statement. + """Handle a type keyword in an SQL statement. Used by the ``Case`` statement. @@ -1610,7 +1610,7 @@ class TextClause(Executable, ClauseElement): class Null(ColumnElement): - """Represent the NULL keyword in a SQL statement. + """Represent the NULL keyword in an SQL statement. :class:`.Null` is accessed as a constant via the :func:`.null` function. @@ -1634,7 +1634,7 @@ class Null(ColumnElement): class False_(ColumnElement): - """Represent the ``false`` keyword, or equivalent, in a SQL statement. + """Represent the ``false`` keyword, or equivalent, in an SQL statement. :class:`.False_` is accessed as a constant via the :func:`.false` function. @@ -1693,7 +1693,7 @@ class False_(ColumnElement): class True_(ColumnElement): - """Represent the ``true`` keyword, or equivalent, in a SQL statement. + """Represent the ``true`` keyword, or equivalent, in an SQL statement. :class:`.True_` is accessed as a constant via the :func:`.true` function. @@ -1966,7 +1966,7 @@ or_ = BooleanClauseList.or_ class Tuple(ClauseList, ColumnElement): - """Represent a SQL tuple.""" + """Represent an SQL tuple.""" def __init__(self, *clauses, **kw): """Return a :class:`.Tuple`. @@ -2306,7 +2306,7 @@ class Cast(ColumnElement): with a specific type, but does not render the ``CAST`` expression in SQL. - :param expression: A SQL expression, such as a :class:`.ColumnElement` + :param expression: An SQL expression, such as a :class:`.ColumnElement` expression or a Python string which will be coerced into a bound literal value. @@ -2354,7 +2354,7 @@ class TypeCoerce(ColumnElement): __visit_name__ = 'type_coerce' def __init__(self, expression, type_): - """Associate a SQL expression with a particular type, without rendering + """Associate an SQL expression with a particular type, without rendering ``CAST``. E.g.:: @@ -2402,7 +2402,7 @@ class TypeCoerce(ColumnElement): except that it does not render the ``CAST`` expression in the resulting statement. - :param expression: A SQL expression, such as a :class:`.ColumnElement` + :param expression: An SQL expression, such as a :class:`.ColumnElement` expression or a Python string which will be coerced into a bound literal value. @@ -2439,7 +2439,7 @@ class TypeCoerce(ColumnElement): class Extract(ColumnElement): - """Represent a SQL EXTRACT clause, ``extract(field FROM expr)``.""" + """Represent an SQL EXTRACT clause, ``extract(field FROM expr)``.""" __visit_name__ = 'extract' @@ -3706,7 +3706,7 @@ class ColumnClause(Immutable, ColumnElement): def _make_proxy(self, selectable, name=None, attach=True, name_is_truncatable=False, **kw): # propagate the "is_literal" flag only if we are keeping our name, - # otherwise its considered to be a label + # otherwise it's considered to be a label is_literal = self.is_literal and (name is None or name == self.name) c = self._constructor( _as_truncated(name or self.name) if @@ -3751,7 +3751,7 @@ class ReleaseSavepointClause(_IdentifiedClause): class quoted_name(util.MemoizedSlots, util.text_type): - """Represent a SQL identifier combined with quoting preferences. + """Represent an SQL identifier combined with quoting preferences. :class:`.quoted_name` is a Python unicode/str subclass which represents a particular identifier name along with a @@ -4125,7 +4125,7 @@ def _no_literals(element): return element.__clause_element__() elif not isinstance(element, Visitable): raise exc.ArgumentError("Ambiguous literal: %r. Use the 'text()' " - "function to indicate a SQL expression " + "function to indicate an SQL expression " "literal, or 'literal()' to indicate a " "bound value." % element) else: diff --git a/lib/sqlalchemy/sql/functions.py b/lib/sqlalchemy/sql/functions.py index e6df07056..288fce39e 100644 --- a/lib/sqlalchemy/sql/functions.py +++ b/lib/sqlalchemy/sql/functions.py @@ -369,7 +369,7 @@ func = _FunctionGenerator() In a few exception cases, the :data:`.func` accessor will redirect a name to a built-in expression such as :func:`.cast` or :func:`.extract`, as these names have well-known meaning - but are not exactly the same as "functions" from a SQLAlchemy + but are not exactly the same as "functions" from an SQLAlchemy perspective. .. versionadded:: 0.8 :data:`.func` can return non-function expression diff --git a/lib/sqlalchemy/sql/operators.py b/lib/sqlalchemy/sql/operators.py index 80f08a97c..33b6baa86 100644 --- a/lib/sqlalchemy/sql/operators.py +++ b/lib/sqlalchemy/sql/operators.py @@ -240,7 +240,7 @@ class ColumnOperators(Operators): :meth:`.operate` or :meth:`.reverse_operate`, passing in the appropriate operator function from the Python builtin ``operator`` module or - a SQLAlchemy-specific operator function from + an SQLAlchemy-specific operator function from :mod:`sqlalchemy.expression.operators`. For example the ``__eq__`` function:: diff --git a/lib/sqlalchemy/sql/schema.py b/lib/sqlalchemy/sql/schema.py index 5e709b1e3..332b494a8 100644 --- a/lib/sqlalchemy/sql/schema.py +++ b/lib/sqlalchemy/sql/schema.py @@ -1918,7 +1918,7 @@ class ColumnDefault(DefaultGenerator): """A plain default value on a column. This could correspond to a constant, a callable function, - or a SQL clause. + or an SQL clause. :class:`.ColumnDefault` is generated automatically whenever the ``default``, ``onupdate`` arguments of @@ -1946,7 +1946,7 @@ class ColumnDefault(DefaultGenerator): * a plain non-callable Python value, such as a string, integer, boolean, or other simple type. The default value will be used as is each time. - * a SQL expression, that is one which derives from + * an SQL expression, that is one which derives from :class:`.ColumnElement`. The SQL expression will be rendered into the INSERT or UPDATE statement, or in the case of a primary key column when @@ -2025,7 +2025,7 @@ class Sequence(DefaultGenerator): The :class:`.Sequence` object represents the name and configurational parameters of a database sequence. It also represents - a construct that can be "executed" by a SQLAlchemy :class:`.Engine` + a construct that can be "executed" by an SQLAlchemy :class:`.Engine` or :class:`.Connection`, rendering the appropriate "next value" function for the target database and returning a result. @@ -2351,7 +2351,7 @@ class Constraint(DialectKWArgs, SchemaItem): def __init__(self, name=None, deferrable=None, initially=None, _create_rule=None, info=None, _type_bound=False, **dialect_kw): - """Create a SQL constraint. + """Create an SQL constraint. :param name: Optional, the in-database name of this ``Constraint``. @@ -2606,7 +2606,7 @@ class CheckConstraint(ColumnCollectionConstraint): :param sqltext: A string containing the constraint definition, which will be used - verbatim, or a SQL expression construct. If given as a string, + verbatim, or an SQL expression construct. If given as a string, the object is converted to a :class:`.Text` object. If the textual string includes a colon character, escape this using a backslash:: diff --git a/lib/sqlalchemy/sql/selectable.py b/lib/sqlalchemy/sql/selectable.py index e299f067e..94b640876 100644 --- a/lib/sqlalchemy/sql/selectable.py +++ b/lib/sqlalchemy/sql/selectable.py @@ -357,7 +357,7 @@ class FromClause(Selectable): may also be a selectable-compatible object such as an ORM-mapped class. - :param onclause: a SQL expression representing the ON clause of the + :param onclause: an SQL expression representing the ON clause of the join. If left at ``None``, :meth:`.FromClause.join` will attempt to join the two tables based on a foreign key relationship. @@ -402,7 +402,7 @@ class FromClause(Selectable): may also be a selectable-compatible object such as an ORM-mapped class. - :param onclause: a SQL expression representing the ON clause of the + :param onclause: an SQL expression representing the ON clause of the join. If left at ``None``, :meth:`.FromClause.join` will attempt to join the two tables based on a foreign key relationship. @@ -767,7 +767,7 @@ class Join(FromClause): may also be a selectable-compatible object such as an ORM-mapped class. - :param onclause: a SQL expression representing the ON clause of the + :param onclause: an SQL expression representing the ON clause of the join. If left at ``None``, :meth:`.FromClause.join` will attempt to join the two tables based on a foreign key relationship. @@ -1124,7 +1124,7 @@ class Alias(FromClause): """Represents an table or selectable alias (AS). Represents an alias, as typically applied to any table or - sub-select within a SQL statement using the ``AS`` keyword (or + sub-select within an SQL statement using the ``AS`` keyword (or without the keyword on certain databases such as Oracle). This object is constructed from the :func:`~.expression.alias` module @@ -1316,7 +1316,7 @@ class HasCTE(object): def cte(self, name=None, recursive=False): """Return a new :class:`.CTE`, or Common Table Expression instance. - Common table expressions are a SQL standard whereby SELECT + Common table expressions are an SQL standard whereby SELECT statements can draw upon secondary statements specified along with the primary statement, using a clause called "WITH". Special semantics regarding UNION can also be employed to @@ -1939,14 +1939,14 @@ class GenerativeSelect(SelectBase): @property def _simple_int_limit(self): """True if the LIMIT clause is a simple integer, False - if it is not present or is a SQL expression. + if it is not present or is an SQL expression. """ return isinstance(self._limit_clause, _OffsetLimitParam) @property def _simple_int_offset(self): """True if the OFFSET clause is a simple integer, False - if it is not present or is a SQL expression. + if it is not present or is an SQL expression. """ return isinstance(self._offset_clause, _OffsetLimitParam) @@ -1973,7 +1973,7 @@ class GenerativeSelect(SelectBase): .. versionchanged:: 1.0.0 - :meth:`.Select.limit` can now accept arbitrary SQL expressions as well as integer values. - :param limit: an integer LIMIT parameter, or a SQL expression + :param limit: an integer LIMIT parameter, or an SQL expression that provides an integer result. """ @@ -1995,7 +1995,7 @@ class GenerativeSelect(SelectBase): .. versionchanged:: 1.0.0 - :meth:`.Select.offset` can now accept arbitrary SQL expressions as well as integer values. - :param offset: an integer OFFSET parameter, or a SQL expression + :param offset: an integer OFFSET parameter, or an SQL expression that provides an integer result. """ @@ -3360,40 +3360,40 @@ class Select(HasPrefixes, HasSuffixes, GenerativeSelect): return FromGrouping(self) def union(self, other, **kwargs): - """return a SQL UNION of this select() construct against the given + """return an SQL UNION of this select() construct against the given selectable.""" return CompoundSelect._create_union(self, other, **kwargs) def union_all(self, other, **kwargs): - """return a SQL UNION ALL of this select() construct against the given + """return an SQL UNION ALL of this select() construct against the given selectable. """ return CompoundSelect._create_union_all(self, other, **kwargs) def except_(self, other, **kwargs): - """return a SQL EXCEPT of this select() construct against the given + """return an SQL EXCEPT of this select() construct against the given selectable.""" return CompoundSelect._create_except(self, other, **kwargs) def except_all(self, other, **kwargs): - """return a SQL EXCEPT ALL of this select() construct against the + """return an SQL EXCEPT ALL of this select() construct against the given selectable. """ return CompoundSelect._create_except_all(self, other, **kwargs) def intersect(self, other, **kwargs): - """return a SQL INTERSECT of this select() construct against the given + """return an SQL INTERSECT of this select() construct against the given selectable. """ return CompoundSelect._create_intersect(self, other, **kwargs) def intersect_all(self, other, **kwargs): - """return a SQL INTERSECT ALL of this select() construct against the + """return an SQL INTERSECT ALL of this select() construct against the given selectable. """ diff --git a/lib/sqlalchemy/sql/sqltypes.py b/lib/sqlalchemy/sql/sqltypes.py index 81630fe4f..97b0b349d 100644 --- a/lib/sqlalchemy/sql/sqltypes.py +++ b/lib/sqlalchemy/sql/sqltypes.py @@ -1636,7 +1636,7 @@ class Interval(_DateAffinity, TypeDecorator): class JSON(Indexable, TypeEngine): - """Represent a SQL JSON type. + """Represent an SQL JSON type. .. note:: :class:`.types.JSON` is provided as a facade for vendor-specific JSON types. Since it supports JSON SQL operations, it only @@ -1850,7 +1850,7 @@ class JSON(Indexable, TypeEngine): class ARRAY(Indexable, Concatenable, TypeEngine): - """Represent a SQL Array type. + """Represent an SQL Array type. .. note:: This type serves as the basis for all ARRAY operations. However, currently **only the Postgresql backend has support @@ -2077,7 +2077,7 @@ class ARRAY(Indexable, Concatenable, TypeEngine): :param as_tuple=False: Specify whether return results should be converted to tuples from lists. This parameter is not generally needed as a Python list corresponds well - to a SQL array. + to an SQL array. :param dimensions: if non-None, the ARRAY will assume a fixed number of dimensions. This impacts how the array is declared @@ -2370,7 +2370,7 @@ def _resolve_value_to_type(value): insp.__class__ in inspection._registrars ): raise exc.ArgumentError( - "Object %r is not legal as a SQL literal value" % value) + "Object %r is not legal as an SQL literal value" % value) return NULLTYPE else: return _result_type diff --git a/lib/sqlalchemy/sql/type_api.py b/lib/sqlalchemy/sql/type_api.py index 2a7adf8af..3193db14d 100644 --- a/lib/sqlalchemy/sql/type_api.py +++ b/lib/sqlalchemy/sql/type_api.py @@ -277,7 +277,7 @@ class TypeEngine(Visitable): def column_expression(self, colexpr): """Given a SELECT column expression, return a wrapping SQL expression. - This is typically a SQL function that wraps a column expression + This is typically an SQL function that wraps a column expression as rendered in the columns clause of a SELECT statement. It is used for special data types that require columns to be wrapped in some special database function in order @@ -310,9 +310,9 @@ class TypeEngine(Visitable): def bind_expression(self, bindvalue): """"Given a bind value (i.e. a :class:`.BindParameter` instance), - return a SQL expression in its place. + return an SQL expression in its place. - This is typically a SQL function that wraps the existing bound + This is typically an SQL function that wraps the existing bound parameter within the statement. It is used for special data types that require literals being wrapped in some special database function in order to coerce an application-level value into a database-specific @@ -501,7 +501,7 @@ class TypeEngine(Visitable): to return a type which the value should be coerced into. The default behavior here is conservative; if the right-hand - side is already coerced into a SQL type based on its + side is already coerced into an SQL type based on its Python type, it is usually left alone. End-user functionality extension here should generally be via @@ -1046,7 +1046,7 @@ class TypeDecorator(SchemaEventTarget, TypeEngine): :meth:`process_bind_param` here. User-defined code can override this method directly, - though its likely best to use :meth:`process_bind_param` so that + although it's likely best to use :meth:`process_bind_param` so that the processing provided by ``self.impl`` is maintained. :param dialect: Dialect instance in use. @@ -1092,7 +1092,7 @@ class TypeDecorator(SchemaEventTarget, TypeEngine): :meth:`process_result_value` here. User-defined code can override this method directly, - though its likely best to use :meth:`process_result_value` so that + although it's likely best to use :meth:`process_result_value` so that the processing provided by ``self.impl`` is maintained. :param dialect: Dialect instance in use. @@ -1124,7 +1124,7 @@ class TypeDecorator(SchemaEventTarget, TypeEngine): By default, returns self. This method is called by the expression system when an object using this type is on the left or right side of an expression against a plain Python - object which does not yet have a SQLAlchemy type assigned:: + object which does not yet have an SQLAlchemy type assigned:: expr = table.c.somecolumn + 35 diff --git a/lib/sqlalchemy/testing/suite/test_results.py b/lib/sqlalchemy/testing/suite/test_results.py index 9ffaa6e04..2dfa8a79a 100644 --- a/lib/sqlalchemy/testing/suite/test_results.py +++ b/lib/sqlalchemy/testing/suite/test_results.py @@ -95,7 +95,7 @@ class RowFetchTest(fixtures.TablesTest): """test that a scalar select as a column is returned as such and that type conversion works OK. - (this is half a SQLAlchemy Core test and half to catch database + (this is half an SQLAlchemy Core test and half to catch database backends that may have unusual behavior with scalar selects.) """ diff --git a/lib/sqlalchemy/util/_collections.py b/lib/sqlalchemy/util/_collections.py index c29b81f6a..5d8764be1 100644 --- a/lib/sqlalchemy/util/_collections.py +++ b/lib/sqlalchemy/util/_collections.py @@ -863,7 +863,7 @@ class LRUCache(dict): recently used items. Note that either get() or [] should be used here, but - generally its not safe to do an "in" check first as the dictionary + generally it's not safe to do an "in" check first as the dictionary can change subsequent to that call. """ diff --git a/test/orm/test_query.py b/test/orm/test_query.py index cdc4ac2c2..526ca6d99 100644 --- a/test/orm/test_query.py +++ b/test/orm/test_query.py @@ -844,34 +844,34 @@ class InvalidGenerationsTest(QueryTest, AssertsCompiledSQL): assert_raises_message( sa_exc.ArgumentError, - "Object .*User.* is not legal as a SQL literal value", + "Object .*User.* is not legal as an SQL literal value", distinct, User ) ua = aliased(User) assert_raises_message( sa_exc.ArgumentError, - "Object .*User.* is not legal as a SQL literal value", + "Object .*User.* is not legal as an SQL literal value", distinct, ua ) s = Session() assert_raises_message( sa_exc.ArgumentError, - "Object .*User.* is not legal as a SQL literal value", + "Object .*User.* is not legal as an SQL literal value", lambda: s.query(User).filter(User.name == User) ) u1 = User() assert_raises_message( sa_exc.ArgumentError, - "Object .*User.* is not legal as a SQL literal value", + "Object .*User.* is not legal as an SQL literal value", distinct, u1 ) assert_raises_message( sa_exc.ArgumentError, - "Object .*User.* is not legal as a SQL literal value", + "Object .*User.* is not legal as an SQL literal value", lambda: s.query(User).filter(User.name == u1) ) @@ -3261,7 +3261,7 @@ class TextTest(QueryTest, AssertsCompiledSQL): # so in general the changing of the query structure with string labels # is dangerous. # - # the queries here are again "invalid" from a SQL perspective, as the + # the queries here are again "invalid" from SQL perspective, as the # "name" field isn't matched up to anything. # with expect_warnings("Can't resolve label reference 'name';"): diff --git a/test/orm/test_relationships.py b/test/orm/test_relationships.py index 061187330..5cde60ade 100644 --- a/test/orm/test_relationships.py +++ b/test/orm/test_relationships.py @@ -355,7 +355,7 @@ class M2ODontOverwriteFKTest(fixtures.MappedTest): class DirectSelfRefFKTest(fixtures.MappedTest, AssertsCompiledSQL): """Tests the ultimate join condition, a single column - that points to itself, e.g. within a SQL function or similar. + that points to itself, e.g. within an SQL function or similar. The test is against a materialized path setup. this is an **extremely** unusual case:: diff --git a/test/sql/test_types.py b/test/sql/test_types.py index 3d527b261..df4bcb9aa 100644 --- a/test/sql/test_types.py +++ b/test/sql/test_types.py @@ -1949,7 +1949,7 @@ class ExpressionTest( assert_raises_message( exc.ArgumentError, - r"Object some_sqla_thing\(\) is not legal as a SQL literal value", + r"Object some_sqla_thing\(\) is not legal as an SQL literal value", lambda: column('a', String) == SomeSQLAThing() ) |