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:16:14 -0400 |
| commit | 180b9955cc8816dba1534257f63c6ce389b10759 (patch) | |
| tree | bd69c5d190d2fc8757c0ed0f49729a23dee7000a /docs/ref/models | |
| parent | 9f69ae78478c1164d24c9e4a656d3cea54d102b1 (diff) | |
[1.6.x] 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'.
Backport of 4d13cc56de from master
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 fe83b54e1c..ad812f6504 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -1177,7 +1177,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 ce943f141d..d5863ec529 100644 --- a/docs/ref/models/instances.txt +++ b/docs/ref/models/instances.txt @@ -419,7 +419,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 fec059a1be..c5b835f55f 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -820,7 +820,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, @@ -950,7 +950,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 |