mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
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'.
This commit is contained in:
@@ -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:
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user