diff options
| author | Eric Boersma <eric.boersma@gmail.com> | 2013-09-05 18:23:48 -0400 |
|---|---|---|
| committer | Tim Graham <timograham@gmail.com> | 2013-09-05 20:14:58 -0400 |
| commit | 4d13cc56de46ccfc89e9f1381ba4f194070bbdb7 (patch) | |
| tree | 5ee6093dd8e9c4d1beb5df46cb16997dad59d6c2 /docs/ref/models | |
| parent | 93dd31cadfb5f02352740aac32bc2f6cdf923b48 (diff) | |
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'.
Diffstat (limited to 'docs/ref/models')
| -rw-r--r-- | docs/ref/models/fields.txt | 2 | ||||
| -rw-r--r-- | docs/ref/models/instances.txt | 2 | ||||
| -rw-r--r-- | docs/ref/models/querysets.txt | 4 |
3 files changed, 4 insertions, 4 deletions
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<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 |