diff --git a/django/contrib/gis/db/models/sql/conversion.py b/django/contrib/gis/db/models/sql/conversion.py index 941c257c75..160b623e6d 100644 --- a/django/contrib/gis/db/models/sql/conversion.py +++ b/django/contrib/gis/db/models/sql/conversion.py @@ -22,6 +22,6 @@ class DistanceField(BaseField): class GeomField(BaseField): """ Wrapper for Geometry values. It is a lightweight alternative to - using GeometryField (which requires a SQL query upon instantiation). + using GeometryField (which requires an SQL query upon instantiation). """ pass diff --git a/django/db/backends/__init__.py b/django/db/backends/__init__.py index 0c1c329202..13078e35ca 100644 --- a/django/db/backends/__init__.py +++ b/django/db/backends/__init__.py @@ -728,7 +728,7 @@ class BaseDatabaseOperations(object): def cache_key_culling_sql(self): """ - Returns a SQL query that retrieves the first cache key greater than the + Returns an SQL query that retrieves the first cache key greater than the n smallest. This is used by the 'db' cache backend to determine where to start @@ -960,7 +960,7 @@ class BaseDatabaseOperations(object): def random_function_sql(self): """ - Returns a SQL expression that returns a random value. + Returns an SQL expression that returns a random value. """ return 'RANDOM()' diff --git a/docs/internals/contributing/writing-documentation.txt b/docs/internals/contributing/writing-documentation.txt index d2cfaddc89..52ad7b7599 100644 --- a/docs/internals/contributing/writing-documentation.txt +++ b/docs/internals/contributing/writing-documentation.txt @@ -78,6 +78,10 @@ documentation: * **MySQL**, **PostgreSQL**, **SQLite** +* **SQL** -- when referring to SQL, the expected pronunciation should be + "Ess Queue Ell" and not "sequel". Thus in a phrase like "Returns an + SQL expression", "SQL" should be preceded by "an" and not "a". + * **Python** -- when referring to the language, capitalize Python. * **realize**, **customize**, **initialize**, etc. -- use the American diff --git a/docs/ref/contrib/gis/testing.txt b/docs/ref/contrib/gis/testing.txt index fca6675345..0e1a98d64d 100644 --- a/docs/ref/contrib/gis/testing.txt +++ b/docs/ref/contrib/gis/testing.txt @@ -33,7 +33,7 @@ database to use. It automatically defaults to ``'template_postgis'`` ^^^^^^^^^^^^^^^^^^^ When GeoDjango's spatial backend initializes on PostGIS, it has to perform -a SQL query to determine the version in order to figure out what +an SQL query to determine the version in order to figure out what features are available. Advanced users wishing to prevent this additional query may set the version manually using a 3-tuple of integers specifying the major, minor, and subminor version numbers for PostGIS. For example, diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 707184c3ac..a4e6724c46 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -635,7 +635,7 @@ Parameters not quoted in ``connection.queries`` ``sqlite3`` does not provide a way to retrieve the SQL after quoting and substituting the parameters. Instead, the SQL in ``connection.queries`` is rebuilt with a simple string interpolation. It may be incorrect. Make sure -you add quotes where necessary before copying a query into a SQLite shell. +you add quotes where necessary before copying a query into an SQLite shell. .. _oracle-notes: diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index 1385648d5d..62058e22d9 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -1519,7 +1519,7 @@ number of roles in which color is used: * ``notice`` - A minor error. * ``sql_field`` - The name of a model field in SQL. * ``sql_coltype`` - The type of a model field in SQL. -* ``sql_keyword`` - A SQL keyword. +* ``sql_keyword`` - An SQL keyword. * ``sql_table`` - The name of a model in SQL. * ``http_info`` - A 1XX HTTP Informational server response. * ``http_success`` - A 2XX HTTP Success server response. diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index 6ef487e90f..194290581e 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -1175,7 +1175,7 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in Take no action. If your database backend enforces referential integrity, this will cause an :exc:`~django.db.IntegrityError` unless - you manually add a SQL ``ON DELETE`` constraint to the database field + you manually add an SQL ``ON DELETE`` constraint to the database field (perhaps using :ref:`initial sql`). .. _ref-manytomany: diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt index d195936964..3ad22fbb12 100644 --- a/docs/ref/models/instances.txt +++ b/docs/ref/models/instances.txt @@ -417,7 +417,7 @@ Deleting objects .. method:: Model.delete([using=DEFAULT_DB_ALIAS]) -Issues a SQL ``DELETE`` for the object. This only deletes the object in the +Issues an SQL ``DELETE`` for the object. This only deletes the object in the database; the Python instance will still exist and will still have data in its fields. diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index 910f7d94d5..c99d27769f 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -802,7 +802,7 @@ This has a similar purpose to ``select_related``, in that both are designed to stop the deluge of database queries that is caused by accessing related objects, but the strategy is quite different. -``select_related`` works by creating a SQL join and including the fields of the +``select_related`` works by creating an SQL join and including the fields of the related object in the ``SELECT`` statement. For this reason, ``select_related`` gets the related objects in the same database query. However, to avoid the much larger result set that would result from joining across a 'many' relationship, @@ -932,7 +932,7 @@ referenced is needed, rather than one query for all the items. There could be additional queries on the ``ContentType`` table if the relevant rows have not already been fetched. -``prefetch_related`` in most cases will be implemented using a SQL query that +``prefetch_related`` in most cases will be implemented using an SQL query that uses the 'IN' operator. This means that for a large ``QuerySet`` a large 'IN' clause could be generated, which, depending on the database, might have performance problems of its own when it comes to parsing or executing the SQL query. Always diff --git a/docs/releases/1.4.4.txt b/docs/releases/1.4.4.txt index c5fcbc3e39..e501e4479a 100644 --- a/docs/releases/1.4.4.txt +++ b/docs/releases/1.4.4.txt @@ -83,6 +83,6 @@ Other bugfixes and changes ========================== * Prevented transaction state from leaking from one request to the next (#19707). -* Changed a SQL command syntax to be MySQL 4 compatible (#19702). +* Changed an SQL command syntax to be MySQL 4 compatible (#19702). * Added backwards-compatibility with old unsalted MD5 passwords (#18144). * Numerous documentation improvements and fixes. diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt index c098aa33e3..51a1028342 100644 --- a/docs/topics/db/multi-db.txt +++ b/docs/topics/db/multi-db.txt @@ -442,7 +442,7 @@ Consider the following example:: In statement 1, a new ``Person`` object is saved to the ``first`` database. At this time, ``p`` doesn't have a primary key, so Django -issues a SQL ``INSERT`` statement. This creates a primary key, and +issues an SQL ``INSERT`` statement. This creates a primary key, and Django assigns that primary key to ``p``. When the save occurs in statement 2, ``p`` already has a primary key @@ -466,7 +466,7 @@ database:: >>> p.save(using='second') # Write a completely new object. The second option is to use the ``force_insert`` option to ``save()`` -to ensure that Django does a SQL ``INSERT``:: +to ensure that Django does an SQL ``INSERT``:: >>> p = Person(name='Fred') >>> p.save(using='first') diff --git a/tests/backends/tests.py b/tests/backends/tests.py index 64f90996d2..e00cdf94ce 100644 --- a/tests/backends/tests.py +++ b/tests/backends/tests.py @@ -403,7 +403,7 @@ class EscapingChecks(TestCase): self.assertEqual(cursor.fetchall()[0], ('%', '%d')) @unittest.skipUnless(connection.vendor == 'sqlite', - "This is a sqlite-specific issue") + "This is an sqlite-specific issue") def test_sqlite_parameter_escaping(self): #13648: '%s' escaping support for sqlite3 cursor = connection.cursor() diff --git a/tests/test_runner/tests.py b/tests/test_runner/tests.py index 7aefa4e077..00b5e9c978 100644 --- a/tests/test_runner/tests.py +++ b/tests/test_runner/tests.py @@ -246,7 +246,7 @@ class Sqlite3InMemoryTestDbs(TestCase): available_apps = [] @unittest.skipUnless(all(db.connections[conn].vendor == 'sqlite' for conn in db.connections), - "This is a sqlite-specific issue") + "This is an sqlite-specific issue") def test_transaction_support(self): """Ticket #16329: sqlite3 in-memory test databases""" old_db_connections = db.connections