Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixed #21035 -- Changed docs to treat the acronym SQL phonetically.

The documentation and comments now all use 'an' to
refer to the word SQL and not 'a'.
  • Loading branch information...
commit 4d13cc56de46ccfc89e9f1381ba4f194070bbdb7 1 parent 93dd31c
@EricBoersma EricBoersma authored timgraham committed
View
2  django/contrib/gis/db/models/sql/conversion.py
@@ -22,6 +22,6 @@ def __init__(self, distance_att):
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
View
4 django/db/backends/__init__.py
@@ -728,7 +728,7 @@ def bulk_batch_size(self, fields, objs):
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 @@ def quote_name(self, name):
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()'
View
4 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
View
2  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,
View
2  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:
View
2  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.
View
2  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<initial-sql>`).
.. _ref-manytomany:
View
2  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.
View
4 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
View
2  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.
View
4 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')
View
2  tests/backends/tests.py
@@ -403,7 +403,7 @@ def test_parameter_escaping(self):
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()
View
2  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
Please sign in to comment.
Something went wrong with that request. Please try again.