newforms-admin: Merged to [4640]

git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@4641 bcc190cf-cafb-0310-a4f2-bffc1f526a37

4 files changed, 35 insertions, 4 deletions

diff --git a/docs/authentication.txt b/docs/authentication.txt
index f5736a3cd7..5186c5672c 100644
--- a/docs/authentication.txt
+++ b/docs/authentication.txt
@@ -86,10 +86,10 @@ objects in the same way as any other `Django model`_::
     myuser.groups.add(group, group,...)
     myuser.groups.remove(group, group,...)
     myuser.groups.clear()
-    myuser.permissions = [permission_list]
-    myuser.permissions.add(permission, permission, ...)
-    myuser.permissions.remove(permission, permission, ...]
-    myuser.permissions.clear()
+    myuser.user_permissions = [permission_list]
+    myuser.user_permissions.add(permission, permission, ...)
+    myuser.user_permissions.remove(permission, permission, ...]
+    myuser.user_permissions.clear()
 
 In addition to those automatic API methods, ``User`` objects have the following
 custom methods:
diff --git a/docs/db-api.txt b/docs/db-api.txt
index 99bb30054b..3dc0efbabd 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -1621,6 +1621,15 @@ For example, this deletes all ``Entry`` objects with a ``pub_date`` year of
 
     Entry.objects.filter(pub_date__year=2005).delete()
 
+When Django deletes an object, it emulates the behavior of the SQL
+constraint ``ON DELETE CASCADE`` -- in other words, any objects which
+had foreign keys pointing at the object to be deleted will be deleted
+along with it. For example::
+
+    b = Blog.objects.get(pk=1)
+    # This will delete the Blog and all of its Entry objects.
+    b.delete()
+
 Note that ``delete()`` is the only ``QuerySet`` method that is not exposed on a
 ``Manager`` itself. This is a safety mechanism to prevent you from accidentally
 requesting ``Entry.objects.delete()``, and deleting *all* the entries. If you
diff --git a/docs/tutorial04.txt b/docs/tutorial04.txt
index 7b19bdaeaf..b1c8c7d4fc 100644
--- a/docs/tutorial04.txt
+++ b/docs/tutorial04.txt
@@ -206,6 +206,21 @@ for the polls app, we manually specify a template name for the results view:
 ``template_name='polls/results.html'``. Otherwise, both views would use the same
 template. Note that we use ``dict()`` to return an altered dictionary in place.
 
+.. note:: ``all()`` is lazy
+
+    It might look a little frightening to see ``Poll.objects.all()`` being used
+    in a detail view which only needs one ``Poll`` object, but don't worry;
+    ``Poll.objects.all()`` is actually a special object called a ``QuerySet``,
+    which is "lazy" and doesn't hit your database until it absolutely has to. By
+    the time the database query happens, the ``object_detail`` generic view will
+    have narrowed its scope down to a single object, so the eventual query will
+    only select one row from the database. 
+    
+    If you'd like to know more about how that works, The Django database API
+    documentation `explains the lazy nature of QuerySet objects`_.
+
+.. _explains the lazy nature of QuerySet objects: ../db_api/#querysets-are-lazy
+
 In previous parts of the tutorial, the templates have been provided with a context
 that contains the ``poll`` and ``latest_poll_list`` context variables. However,
 the generic views provide the variables ``object`` and ``object_list`` as context.
diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt
index da4be2c746..3f51ce4b91 100644
--- a/docs/url_dispatch.txt
+++ b/docs/url_dispatch.txt
@@ -390,6 +390,13 @@ to pass metadata and options to views.
 .. _generic views: ../generic_views/
 .. _syndication framework: ../syndication/
 
+.. admonition:: Dealing with conflicts
+
+    It's possible to have a URL pattern which captures named keyword arguments,
+    and also passes arguments with the same names in its dictionary of extra
+    arguments. When this happens, the arguments in the dictionary will be used
+    instead of the arguments captured in the URL.
+
 Passing extra options to ``include()``
 --------------------------------------