mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Fixed #16014 -- numerous documentation typos -- thanks psmith.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16220 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
@@ -396,7 +396,7 @@ developers of other reusable apps that want the same guarantees also use the
|
||||
Settings
|
||||
========
|
||||
|
||||
A number of settings can be used to control Django's CSRF behaviour.
|
||||
A number of settings can be used to control Django's CSRF behavior.
|
||||
|
||||
CSRF_COOKIE_DOMAIN
|
||||
------------------
|
||||
|
||||
@@ -86,7 +86,7 @@ does all of the work.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Redirects by the middlware are permanent (301 status code) instead of
|
||||
temporary (302) to match behaviour of the
|
||||
temporary (302) to match behavior of the
|
||||
:class:`~django.middleware.common.CommonMiddleware`.
|
||||
|
||||
If it doesn't find a match, the request continues to be processed as usual.
|
||||
|
||||
@@ -361,6 +361,6 @@ considering aren't valid, we must remember to remove them from the
|
||||
``cleaned_data``.
|
||||
|
||||
In fact, Django will currently completely wipe out the ``cleaned_data``
|
||||
dictionary if there are any errors in the form. However, this behaviour may
|
||||
dictionary if there are any errors in the form. However, this behavior may
|
||||
change in the future, so it's not a bad idea to clean up after yourself in the
|
||||
first place.
|
||||
|
||||
@@ -986,7 +986,7 @@ locks on them.
|
||||
|
||||
Usually, if another transaction has already acquired a lock on one of the
|
||||
selected rows, the query will block until the lock is released. If this is
|
||||
not the behaviour you want, call ``select_for_update(nowait=True)``. This will
|
||||
not the behavior you want, call ``select_for_update(nowait=True)``. This will
|
||||
make the call non-blocking. If a conflicting lock is already acquired by
|
||||
another transaction, ``django.db.utils.DatabaseError`` will be raised when
|
||||
the queryset is evaluated.
|
||||
@@ -1124,7 +1124,7 @@ If you have a field named ``defaults`` and want to use it as an exact lookup in
|
||||
Foo.objects.get_or_create(defaults__exact='bar', defaults={'defaults': 'baz'})
|
||||
|
||||
|
||||
The ``get_or_create()`` method has similar error behaviour to ``create()``
|
||||
The ``get_or_create()`` method has similar error behavior to ``create()``
|
||||
when you are using manually specified primary keys. If an object needs to be
|
||||
created and the key already exists in the database, an ``IntegrityError`` will
|
||||
be raised.
|
||||
|
||||
Reference in New Issue
Block a user