From cb64f5375cc1884226cad05b671e8660214a4a92 Mon Sep 17 00:00:00 2001 From: Justin Bronn Date: Sun, 26 Aug 2007 17:47:34 +0000 Subject: gis: Merged revisions 6000-6020 via svnmerge from [repos:django/trunk trunk]. git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@6021 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/db-api.txt | 19 ++++++++++++++----- docs/django-admin.txt | 24 ++++++++++++++++++++---- docs/faq.txt | 4 ---- docs/model-api.txt | 2 +- docs/newforms.txt | 2 +- docs/settings.txt | 9 +++++---- docs/templates.txt | 12 ++++++++++-- docs/tutorial01.txt | 33 +++++++++++++++++++++++++++++++++ 8 files changed, 84 insertions(+), 21 deletions(-) (limited to 'docs') diff --git a/docs/db-api.txt b/docs/db-api.txt index 766a6ae519..3198f335c4 100644 --- a/docs/db-api.txt +++ b/docs/db-api.txt @@ -207,14 +207,23 @@ the database until you explicitly call ``save()``. The ``save()`` method has no return value. -Updating ``ForeignKey`` fields works exactly the same way; simply assign an -object of the right type to the field in question:: +Saving ForeignKey and ManyToManyField fields +-------------------------------------------- + +Updating ``ForeignKey`` fields works exactly the same way as saving a normal +field; simply assign an object of the right type to the field in question:: + + cheese_blog = Blog.objects.get(name="Cheddar Talk") + entry.blog = cheese_blog + entry.save() + +Updating a ``ManyToManyField`` works a little differently; use the ``add()`` +method on the field to add a record to the relation:: joe = Author.objects.create(name="Joe") - entry.author = joe - entry.save() + entry.authors.add(joe) -Django will complain if you try to assign an object of the wrong type. +Django will complain if you try to assign or add an object of the wrong type. How Django knows to UPDATE vs. INSERT ------------------------------------- diff --git a/docs/django-admin.txt b/docs/django-admin.txt index aea990c5dc..e3d1067dd3 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -124,6 +124,13 @@ executed. This means that all data will be removed from the database, any post-synchronization handlers will be re-executed, and the ``initial_data`` fixture will be re-installed. +The behavior of this command has changed in the Django development version. +Previously, this command cleared *every* table in the database, including any +table that Django didn't know about (i.e., tables that didn't have associated +models and/or weren't in ``INSTALLED_APPS``). Now, the command only clears +tables that are represented by Django models and are activated in +``INSTALLED_APPS``. + inspectdb --------- @@ -240,6 +247,7 @@ Executes the equivalent of ``sqlreset`` for the given appnames. runfcgi [options] ----------------- + Starts a set of FastCGI processes suitable for use with any web server which supports the FastCGI protocol. See the `FastCGI deployment documentation`_ for details. Requires the Python FastCGI module from @@ -337,7 +345,7 @@ Refer to the description of ``sqlcustom`` for an explanation of how to specify initial data. sqlclear [appname appname ...] --------------------------------------- +------------------------------ Prints the DROP TABLE SQL statements for the given appnames. @@ -360,18 +368,23 @@ table modifications, or insert any SQL functions into the database. Note that the order in which the SQL files are processed is undefined. +sqlflush +-------- + +Prints the SQL statements that would be executed for the `flush`_ command. + sqlindexes [appname appname ...] ----------------------------------------- +-------------------------------- Prints the CREATE INDEX SQL statements for the given appnames. sqlreset [appname appname ...] --------------------------------------- +------------------------------ Prints the DROP TABLE SQL, then the CREATE TABLE SQL, for the given appnames. sqlsequencereset [appname appname ...] ----------------------------------------------- +-------------------------------------- Prints the SQL statements for resetting sequences for the given appnames. @@ -466,6 +479,9 @@ This is useful in a number of ways: Note that this server can only run on the default port on localhost; it does not yet accept a ``host`` or ``port`` parameter. +Also note that it does *not* automatically detect changes to your Python source +code (as ``runserver`` does). It does, however, detect changes to templates. + .. _unit tests: ../testing/ validate diff --git a/docs/faq.txt b/docs/faq.txt index 844ea77809..cef0508562 100644 --- a/docs/faq.txt +++ b/docs/faq.txt @@ -204,10 +204,6 @@ out a few points, we want to make sure they reflect the final state of things at Django 1.0, not some intermediary step. In other words, we don't want to spend a lot of energy creating screencasts yet, because Django APIs will shift. -In the meantime, though, check out this `unofficial Django screencast`_. - -.. _unofficial Django screencast: http://www.throwingbeans.org/django_screencasts.html - Is Django a content-management-system (CMS)? -------------------------------------------- diff --git a/docs/model-api.txt b/docs/model-api.txt index 0f872c3097..7dac54992f 100644 --- a/docs/model-api.txt +++ b/docs/model-api.txt @@ -344,7 +344,7 @@ development version. See the `Django 0.96 documentation`_ for the old behavior. ``ImageField`` ~~~~~~~~~~~~~~ -Like ``FileField``, but validates that the uploaded object is a valid +Like `FileField`_, but validates that the uploaded object is a valid image. Has two extra optional arguments, ``height_field`` and ``width_field``, which, if set, will be auto-populated with the height and width of the image each time a model instance is saved. diff --git a/docs/newforms.txt b/docs/newforms.txt index 0b59a7ad65..36c627b398 100644 --- a/docs/newforms.txt +++ b/docs/newforms.txt @@ -1554,7 +1554,7 @@ as a custom extension to the ``TextInput`` widget:: class CommentWidget(forms.TextInput): def __init__(self, *args, **kwargs): kwargs.setdefault('attrs',{}).update({'size': '40'}) - super(forms.TextInput, self).__init__(*args, **kwargs) + super(CommentWidget, self).__init__(*args, **kwargs) Then you can use this widget in your forms:: diff --git a/docs/settings.txt b/docs/settings.txt index 050e377713..3f98296778 100644 --- a/docs/settings.txt +++ b/docs/settings.txt @@ -1101,10 +1101,11 @@ To disable this behavior, just remove all entries from the ``ADMINS`` setting. 404 errors ---------- -When ``DEBUG`` is ``False`` and your ``MIDDLEWARE_CLASSES`` setting includes -``CommonMiddleware``, Django will e-mail the users listed in the ``MANAGERS`` -setting whenever your code raises a 404 and the request has a referer. -(It doesn't bother to e-mail for 404s that don't have a referer.) +When ``DEBUG`` is ``False``, ``SEND_BROKEN_LINK_EMAILS`` is ``True`` and your +``MIDDLEWARE_CLASSES`` setting includes ``CommonMiddleware``, Django will +e-mail the users listed in the ``MANAGERS`` setting whenever your code raises +a 404 and the request has a referer. (It doesn't bother to e-mail for 404s +that don't have a referer.) You can tell Django to stop reporting particular 404s by tweaking the ``IGNORABLE_404_ENDS`` and ``IGNORABLE_404_STARTS`` settings. Both should be a diff --git a/docs/templates.txt b/docs/templates.txt index 6cebd3b7bd..8bfa40dc5f 100644 --- a/docs/templates.txt +++ b/docs/templates.txt @@ -1301,9 +1301,14 @@ unordered_list Recursively takes a self-nested list and returns an HTML unordered list -- WITHOUT opening and closing