[Python-modules-commits] [python-django] 01/04: Imported Upstream version 1.7
Raphaël Hertzog
hertzog at moszumanska.debian.org
Mon Sep 8 08:49:32 UTC 2014
This is an automated email from the git hooks/post-receive script.
hertzog pushed a commit to branch debian/experimental
in repository python-django.
commit 2a5c21fb0889ac4260395af8743b809e18133312
Author: Raphaël Hertzog <hertzog at debian.org>
Date: Mon Sep 8 10:18:44 2014 +0200
Imported Upstream version 1.7
---
AUTHORS | 1 +
Django.egg-info/PKG-INFO | 2 +-
Django.egg-info/SOURCES.txt | 3 +
PKG-INFO | 2 +-
django/__init__.py | 2 +-
django/conf/global_settings.py | 3 +
django/conf/locale/__init__.py | 18 +++
django/conf/locale/en/LC_MESSAGES/django.po | 14 +-
django/contrib/admin/options.py | 10 +-
.../contrib/admin/templates/admin/change_form.html | 2 +-
.../contrib/admin/templates/admin/change_list.html | 2 +-
django/contrib/admin/tests.py | 4 +-
django/contrib/staticfiles/testing.py | 2 +-
django/core/management/sql.py | 2 +-
django/db/backends/oracle/base.py | 23 ++-
django/db/backends/oracle/creation.py | 2 +
django/db/migrations/graph.py | 6 +-
django/db/migrations/loader.py | 6 +-
django/db/migrations/operations/special.py | 4 +-
django/db/models/query.py | 6 +-
django/utils/translation/__init__.py | 2 +-
docs/howto/custom-file-storage.txt | 2 +-
docs/howto/static-files/index.txt | 6 +-
.../contributing/writing-code/unit-tests.txt | 2 +-
docs/internals/howto-release-django.txt | 3 +-
docs/intro/tutorial01.txt | 2 +-
docs/ref/class-based-views/generic-date-based.txt | 2 +-
docs/ref/class-based-views/index.txt | 6 +-
docs/ref/contrib/admin/index.txt | 1 +
docs/ref/contrib/sites.txt | 8 +-
docs/ref/contrib/staticfiles.txt | 6 +-
docs/ref/databases.txt | 9 ++
docs/ref/django-admin.txt | 3 +
docs/ref/files/storage.txt | 2 +-
docs/ref/forms/fields.txt | 17 ++-
docs/ref/forms/validation.txt | 2 +-
docs/ref/forms/widgets.txt | 7 +-
docs/ref/models/fields.txt | 2 +-
docs/ref/settings.txt | 19 ++-
docs/ref/signals.txt | 6 +-
docs/ref/templates/api.txt | 25 ++++
docs/releases/1.4.14.txt | 2 +-
docs/releases/1.4.15.txt | 13 ++
docs/releases/1.5.10.txt | 13 ++
docs/releases/1.5.9.txt | 2 +-
docs/releases/1.6.6.txt | 2 +-
docs/releases/1.6.7.txt | 16 ++
docs/releases/1.7.txt | 37 +++--
docs/releases/index.txt | 3 +
docs/releases/security.txt | 120 +++++++++++++--
docs/topics/auth/index.txt | 5 +-
docs/topics/class-based-views/generic-display.txt | 6 +-
docs/topics/db/multi-db.txt | 24 ++-
docs/topics/forms/index.txt | 10 ++
docs/topics/http/file-uploads.txt | 49 +-----
docs/topics/http/urls.txt | 164 +++++++++++++--------
docs/topics/i18n/timezones.txt | 3 +-
docs/topics/i18n/translation.txt | 7 +-
docs/topics/migrations.txt | 19 ++-
docs/topics/testing/tools.txt | 6 +-
tests/admin_views/admin.py | 6 +-
tests/admin_views/models.py | 17 +++
tests/admin_views/tests.py | 9 ++
tests/apps/tests.py | 2 +-
tests/commands_sql/tests.py | 28 +++-
tests/contenttypes_tests/tests.py | 2 +-
tests/i18n/tests.py | 11 ++
tests/migrations/test_autodetector.py | 4 +-
tests/migrations/test_graph.py | 76 +++++++---
tests/migrations/test_operations.py | 33 +++++
tests/model_inheritance/tests.py | 37 +++++
tests/schema/tests.py | 4 +-
tests/staticfiles_tests/test_liveserver.py | 10 +-
73 files changed, 728 insertions(+), 258 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index 40196ef..37fd21c 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -61,6 +61,7 @@ answer newbie questions, and generally made Django that much better:
Mathieu Agopian <mathieu.agopian at gmail.com>
Roberto Aguilar <roberto at baremetal.io>
ajs <adi at sieker.info>
+ Akis Kesoglou <akiskesoglou at gmail.com>
alang at bright-green.com
A S Alam <aalam at users.sf.net>
Andi Albrecht <albrecht.andi at gmail.com>
diff --git a/Django.egg-info/PKG-INFO b/Django.egg-info/PKG-INFO
index 569a099..b376b2b 100644
--- a/Django.egg-info/PKG-INFO
+++ b/Django.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: Django
-Version: 1.7c3
+Version: 1.7
Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Home-page: http://www.djangoproject.com/
Author: Django Software Foundation
diff --git a/Django.egg-info/SOURCES.txt b/Django.egg-info/SOURCES.txt
index 60139c5..b0445b4 100644
--- a/Django.egg-info/SOURCES.txt
+++ b/Django.egg-info/SOURCES.txt
@@ -3990,6 +3990,7 @@ docs/releases/1.4.11.txt
docs/releases/1.4.12.txt
docs/releases/1.4.13.txt
docs/releases/1.4.14.txt
+docs/releases/1.4.15.txt
docs/releases/1.4.2.txt
docs/releases/1.4.3.txt
docs/releases/1.4.4.txt
@@ -4002,6 +4003,7 @@ docs/releases/1.4.txt
docs/releases/1.5-alpha-1.txt
docs/releases/1.5-beta-1.txt
docs/releases/1.5.1.txt
+docs/releases/1.5.10.txt
docs/releases/1.5.2.txt
docs/releases/1.5.3.txt
docs/releases/1.5.4.txt
@@ -4017,6 +4019,7 @@ docs/releases/1.6.3.txt
docs/releases/1.6.4.txt
docs/releases/1.6.5.txt
docs/releases/1.6.6.txt
+docs/releases/1.6.7.txt
docs/releases/1.6.txt
docs/releases/1.7.txt
docs/releases/index.txt
diff --git a/PKG-INFO b/PKG-INFO
index 569a099..b376b2b 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: Django
-Version: 1.7c3
+Version: 1.7
Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Home-page: http://www.djangoproject.com/
Author: Django Software Foundation
diff --git a/django/__init__.py b/django/__init__.py
index 0a4c2d0..133e5e3 100644
--- a/django/__init__.py
+++ b/django/__init__.py
@@ -1,4 +1,4 @@
-VERSION = (1, 7, 0, 'rc', 3)
+VERSION = (1, 7, 0, 'final', 0)
def get_version(*args, **kwargs):
diff --git a/django/conf/global_settings.py b/django/conf/global_settings.py
index 38d836a..c1f77af 100644
--- a/django/conf/global_settings.py
+++ b/django/conf/global_settings.py
@@ -50,6 +50,7 @@ LANGUAGE_CODE = 'en-us'
LANGUAGES = (
('af', gettext_noop('Afrikaans')),
('ar', gettext_noop('Arabic')),
+ ('ast', gettext_noop('Asturian')),
('az', gettext_noop('Azerbaijani')),
('bg', gettext_noop('Bulgarian')),
('be', gettext_noop('Belarusian')),
@@ -85,6 +86,7 @@ LANGUAGES = (
('hu', gettext_noop('Hungarian')),
('ia', gettext_noop('Interlingua')),
('id', gettext_noop('Indonesian')),
+ ('io', gettext_noop('Ido')),
('is', gettext_noop('Icelandic')),
('it', gettext_noop('Italian')),
('ja', gettext_noop('Japanese')),
@@ -99,6 +101,7 @@ LANGUAGES = (
('mk', gettext_noop('Macedonian')),
('ml', gettext_noop('Malayalam')),
('mn', gettext_noop('Mongolian')),
+ ('mr', gettext_noop('Marathi')),
('my', gettext_noop('Burmese')),
('nb', gettext_noop('Norwegian Bokmal')),
('ne', gettext_noop('Nepali')),
diff --git a/django/conf/locale/__init__.py b/django/conf/locale/__init__.py
index 77f8e95..0c7f0e1 100644
--- a/django/conf/locale/__init__.py
+++ b/django/conf/locale/__init__.py
@@ -17,6 +17,12 @@ LANG_INFO = {
'name': 'Arabic',
'name_local': 'العربيّة',
},
+ 'ast': {
+ 'bidi': False,
+ 'code': 'ast',
+ 'name': 'Asturian',
+ 'name_local': 'asturianu',
+ },
'az': {
'bidi': True,
'code': 'az',
@@ -221,6 +227,12 @@ LANG_INFO = {
'name': 'Interlingua',
'name_local': 'Interlingua',
},
+ 'io': {
+ 'bidi': False,
+ 'code': 'io',
+ 'name': 'Ido',
+ 'name_local': 'ido',
+ },
'id': {
'bidi': False,
'code': 'id',
@@ -311,6 +323,12 @@ LANG_INFO = {
'name': 'Mongolian',
'name_local': 'Mongolian',
},
+ 'mr': {
+ 'bidi': False,
+ 'code': 'mr',
+ 'name': 'Marathi',
+ 'name_local': 'मराठी',
+ },
'my': {
'bidi': False,
'code': 'my',
diff --git a/django/conf/locale/en/LC_MESSAGES/django.po b/django/conf/locale/en/LC_MESSAGES/django.po
index a1dbc22..dbfc883 100644
--- a/django/conf/locale/en/LC_MESSAGES/django.po
+++ b/django/conf/locale/en/LC_MESSAGES/django.po
@@ -4,7 +4,7 @@ msgid ""
msgstr ""
"Project-Id-Version: Django\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2014-07-26 13:48+0200\n"
+"POT-Creation-Date: 2014-08-23 14:10+0200\n"
"PO-Revision-Date: 2010-05-13 15:35+0200\n"
"Last-Translator: Django team\n"
"Language-Team: English <en at li.org>\n"
@@ -22,6 +22,10 @@ msgid "Arabic"
msgstr ""
#: conf/global_settings.py:53
+msgid "Asturian"
+msgstr ""
+
+#: conf/global_settings.py:53
msgid "Azerbaijani"
msgstr ""
@@ -162,6 +166,10 @@ msgid "Indonesian"
msgstr ""
#: conf/global_settings.py:88
+msgid "Ido"
+msgstr ""
+
+#: conf/global_settings.py:88
msgid "Icelandic"
msgstr ""
@@ -218,6 +226,10 @@ msgid "Mongolian"
msgstr ""
#: conf/global_settings.py:102
+msgid "Marathi"
+msgstr ""
+
+#: conf/global_settings.py:102
msgid "Burmese"
msgstr ""
diff --git a/django/contrib/admin/options.py b/django/contrib/admin/options.py
index 7dd2430..3a48cb7 100644
--- a/django/contrib/admin/options.py
+++ b/django/contrib/admin/options.py
@@ -444,11 +444,13 @@ class BaseModelAdmin(six.with_metaclass(RenameBaseModelAdminMethods)):
return False
# Make sure at least one of the models registered for this site
- # references this field.
+ # references this field through a FK or a M2M relationship.
registered_models = self.admin_site._registry
- for related_object in opts.get_all_related_objects():
- if (related_object.model in registered_models and
- field in related_object.field.foreign_related_fields):
+ for related_object in (opts.get_all_related_objects() +
+ opts.get_all_related_many_to_many_objects()):
+ related_model = related_object.model
+ if (any(issubclass(model, related_model) for model in registered_models) and
+ related_object.field.rel.get_related_field() == field):
return True
return False
diff --git a/django/contrib/admin/templates/admin/change_form.html b/django/contrib/admin/templates/admin/change_form.html
index d68f71e..7c7100f 100644
--- a/django/contrib/admin/templates/admin/change_form.html
+++ b/django/contrib/admin/templates/admin/change_form.html
@@ -37,7 +37,7 @@
</ul>
{% endif %}{% endif %}
{% endblock %}
-<form {% if has_file_field %}enctype="multipart/form-data" {% endif %}action="{{ form_url }}" method="post" id="{{ opts.model_name }}_form">{% csrf_token %}{% block form_top %}{% endblock %}
+<form {% if has_file_field %}enctype="multipart/form-data" {% endif %}action="{{ form_url }}" method="post" id="{{ opts.model_name }}_form" novalidate>{% csrf_token %}{% block form_top %}{% endblock %}
<div>
{% if is_popup %}<input type="hidden" name="{{ is_popup_var }}" value="1" />{% endif %}
{% if to_field %}<input type="hidden" name="{{ to_field_var }}" value="{{ to_field }}" />{% endif %}
diff --git a/django/contrib/admin/templates/admin/change_list.html b/django/contrib/admin/templates/admin/change_list.html
index 586942d..ca0080e 100644
--- a/django/contrib/admin/templates/admin/change_list.html
+++ b/django/contrib/admin/templates/admin/change_list.html
@@ -81,7 +81,7 @@
{% endif %}
{% endblock %}
- <form id="changelist-form" action="" method="post"{% if cl.formset.is_multipart %} enctype="multipart/form-data"{% endif %}>{% csrf_token %}
+ <form id="changelist-form" action="" method="post"{% if cl.formset.is_multipart %} enctype="multipart/form-data"{% endif %} novalidate>{% csrf_token %}
{% if cl.formset %}
<div>{{ cl.formset.management_form }}</div>
{% endif %}
diff --git a/django/contrib/admin/tests.py b/django/contrib/admin/tests.py
index cd18868..d7780da 100644
--- a/django/contrib/admin/tests.py
+++ b/django/contrib/admin/tests.py
@@ -1,12 +1,12 @@
import os
from unittest import SkipTest
-from django.contrib.staticfiles.testing import StaticLiveServerCase
+from django.contrib.staticfiles.testing import StaticLiveServerTestCase
from django.utils.module_loading import import_string
from django.utils.translation import ugettext as _
-class AdminSeleniumWebDriverTestCase(StaticLiveServerCase):
+class AdminSeleniumWebDriverTestCase(StaticLiveServerTestCase):
available_apps = [
'django.contrib.admin',
diff --git a/django/contrib/staticfiles/testing.py b/django/contrib/staticfiles/testing.py
index 8683239..7b30499 100644
--- a/django/contrib/staticfiles/testing.py
+++ b/django/contrib/staticfiles/testing.py
@@ -3,7 +3,7 @@ from django.test import LiveServerTestCase
from django.contrib.staticfiles.handlers import StaticFilesHandler
-class StaticLiveServerCase(LiveServerTestCase):
+class StaticLiveServerTestCase(LiveServerTestCase):
"""
Extends django.test.LiveServerTestCase to transparently overlay at test
execution-time the assets provided by the staticfiles app finders. This
diff --git a/django/core/management/sql.py b/django/core/management/sql.py
index 323cb54..a834627 100644
--- a/django/core/management/sql.py
+++ b/django/core/management/sql.py
@@ -36,7 +36,7 @@ def sql_create(app_config, style, connection):
# We trim models from the current app so that the sqlreset command does not
# generate invalid SQL (leaving models out of known_models is harmless, so
# we can be conservative).
- app_models = app_config.get_models(include_auto_created=True)
+ app_models = list(app_config.get_models(include_auto_created=True))
final_output = []
tables = connection.introspection.table_names()
known_models = set(model for model in connection.introspection.installed_models(tables) if model not in app_models)
diff --git a/django/db/backends/oracle/base.py b/django/db/backends/oracle/base.py
index 4e05513..c4ad9e9 100644
--- a/django/db/backends/oracle/base.py
+++ b/django/db/backends/oracle/base.py
@@ -725,14 +725,31 @@ class DatabaseWrapper(BaseDatabaseWrapper):
return True
@cached_property
- def oracle_version(self):
+ def oracle_full_version(self):
with self.temporary_connection():
- version = self.connection.version
+ return self.connection.version
+
+ @cached_property
+ def oracle_version(self):
try:
- return int(version.split('.')[0])
+ return int(self.oracle_full_version.split('.')[0])
except ValueError:
return None
+ @cached_property
+ def version_has_default_introspection_bug(self):
+ """
+ Some versions of Oracle -- we've seen this on 11.2.0.1 and suspect
+ it goes back -- have a weird bug where, when an integer column is
+ defined with a default, its precision is later reported on introspection
+ as 0, regardless of the real precision. For Django introspection, this
+ means that such columns are reported as IntegerField even if they are
+ really BigIntegerField or BooleanField.
+
+ The bug is solved in Oracle 11.2.0.2 and up.
+ """
+ return self.oracle_full_version < '11.2.0.2'
+
class OracleParam(object):
"""
diff --git a/django/db/backends/oracle/creation.py b/django/db/backends/oracle/creation.py
index 90cc83f..79e7f4c 100644
--- a/django/db/backends/oracle/creation.py
+++ b/django/db/backends/oracle/creation.py
@@ -116,6 +116,8 @@ class DatabaseCreation(BaseDatabaseCreation):
print("Tests cancelled.")
sys.exit(1)
+ self.connection.close() # done with main user -- test user and tablespaces created
+
real_settings = settings.DATABASES[self.connection.alias]
real_settings['SAVED_USER'] = self.connection.settings_dict['SAVED_USER'] = self.connection.settings_dict['USER']
real_settings['SAVED_PASSWORD'] = self.connection.settings_dict['SAVED_PASSWORD'] = self.connection.settings_dict['PASSWORD']
diff --git a/django/db/migrations/graph.py b/django/db/migrations/graph.py
index 59578b1..27b4105 100644
--- a/django/db/migrations/graph.py
+++ b/django/db/migrations/graph.py
@@ -35,11 +35,11 @@ class MigrationGraph(object):
def add_node(self, node, implementation):
self.nodes[node] = implementation
- def add_dependency(self, child, parent):
+ def add_dependency(self, migration, child, parent):
if child not in self.nodes:
- raise KeyError("Dependency references nonexistent child node %r" % (child,))
+ raise KeyError("Migration %s dependencies references nonexistent child node %r" % (migration, child))
if parent not in self.nodes:
- raise KeyError("Dependency references nonexistent parent node %r" % (parent,))
+ raise KeyError("Migration %s dependencies references nonexistent parent node %r" % (migration, parent))
self.dependencies.setdefault(child, set()).add(parent)
self.dependents.setdefault(parent, set()).add(child)
diff --git a/django/db/migrations/loader.py b/django/db/migrations/loader.py
index 2fb2098..9a3dd80 100644
--- a/django/db/migrations/loader.py
+++ b/django/db/migrations/loader.py
@@ -230,7 +230,7 @@ class MigrationLoader(object):
if parent[0] != key[0] or parent[1] == '__first__':
# Ignore __first__ references to the same app (#22325)
continue
- self.graph.add_dependency(key, parent)
+ self.graph.add_dependency(migration, key, parent)
for key, migration in normal.items():
for parent in migration.dependencies:
if parent[0] == key[0]:
@@ -238,11 +238,11 @@ class MigrationLoader(object):
continue
parent = self.check_key(parent, key[0])
if parent is not None:
- self.graph.add_dependency(key, parent)
+ self.graph.add_dependency(migration, key, parent)
for child in migration.run_before:
child = self.check_key(child, key[0])
if child is not None:
- self.graph.add_dependency(child, key)
+ self.graph.add_dependency(migration, child, key)
def detect_conflicts(self):
"""
diff --git a/django/db/migrations/operations/special.py b/django/db/migrations/operations/special.py
index b7ffbbb..fe5f00a 100644
--- a/django/db/migrations/operations/special.py
+++ b/django/db/migrations/operations/special.py
@@ -24,7 +24,7 @@ class SeparateDatabaseAndState(Operation):
for database_operation in self.database_operations:
to_state = from_state.clone()
database_operation.state_forwards(app_label, to_state)
- database_operation.database_forwards(self, app_label, schema_editor, from_state, to_state)
+ database_operation.database_forwards(app_label, schema_editor, from_state, to_state)
from_state = to_state
def database_backwards(self, app_label, schema_editor, from_state, to_state):
@@ -36,7 +36,7 @@ class SeparateDatabaseAndState(Operation):
dbop.state_forwards(app_label, to_state)
from_state = base_state.clone()
database_operation.state_forwards(app_label, from_state)
- database_operation.database_backwards(self, app_label, schema_editor, from_state, to_state)
+ database_operation.database_backwards(app_label, schema_editor, from_state, to_state)
def describe(self):
return "Custom state/database change combination"
diff --git a/django/db/models/query.py b/django/db/models/query.py
index 30fd786..22919e5 100644
--- a/django/db/models/query.py
+++ b/django/db/models/query.py
@@ -1332,12 +1332,12 @@ def get_klass_info(klass, max_depth=0, cur_depth=0, requested=None,
init_list = []
# Build the list of fields that *haven't* been requested
for field, model in klass._meta.get_concrete_fields_with_model():
- if field.name not in load_fields:
- skip.add(field.attname)
- elif from_parent and issubclass(from_parent, model.__class__):
+ if from_parent and model and issubclass(from_parent, model):
# Avoid loading fields already loaded for parent model for
# child models.
continue
+ elif field.name not in load_fields:
+ skip.add(field.attname)
else:
init_list.append(field.attname)
# Retrieve all the requested fields
diff --git a/django/utils/translation/__init__.py b/django/utils/translation/__init__.py
index 6be6645..0318247 100644
--- a/django/utils/translation/__init__.py
+++ b/django/utils/translation/__init__.py
@@ -100,7 +100,7 @@ pgettext_lazy = lazy(pgettext, six.text_type)
def lazy_number(func, resultclass, number=None, **kwargs):
- if isinstance(number, int):
+ if isinstance(number, six.integer_types):
kwargs['number'] = number
proxy = lazy(func, resultclass)(**kwargs)
else:
diff --git a/docs/howto/custom-file-storage.txt b/docs/howto/custom-file-storage.txt
index afa1c9a..56aa479 100644
--- a/docs/howto/custom-file-storage.txt
+++ b/docs/howto/custom-file-storage.txt
@@ -97,7 +97,7 @@ to the ``get_valid_name()`` method described above.
extension.
Previously, an underscore followed by a number (e.g. ``"_1"``, ``"_2"``,
- etc.) was appended to the filename until an avaible name in the destination
+ etc.) was appended to the filename until an available name in the destination
directory was found. A malicious user could exploit this deterministic
algorithm to create a denial-of-service attack. This change was also made
in Django 1.6.6, 1.5.9, and 1.4.14.
diff --git a/docs/howto/static-files/index.txt b/docs/howto/static-files/index.txt
index fea9866..2525881 100644
--- a/docs/howto/static-files/index.txt
+++ b/docs/howto/static-files/index.txt
@@ -152,7 +152,7 @@ file-serving functionality: It doesn't know about the finders feature of the
collected under :setting:`STATIC_ROOT`.
Because of this, ``staticfiles`` ships its own
-:class:`django.contrib.staticfiles.testing.StaticLiveServerCase`, a subclass
+:class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase`, a subclass
of the built-in one that has the ability to transparently serve all the assets
during execution of these tests in a way very similar to what we get at
development time with ``DEBUG = True``, i.e. without having to collect them
@@ -160,8 +160,8 @@ using :djadmin:`collectstatic` first.
.. versionadded:: 1.7
- :class:`django.contrib.staticfiles.testing.StaticLiveServerCase` is new in
- Django 1.7. Previously its functionality was provided by
+ :class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase` is new
+ in Django 1.7. Previously its functionality was provided by
:class:`django.test.LiveServerTestCase`.
Deployment
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index 3d0df10..c071782 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -30,7 +30,7 @@ sample settings module that uses the SQLite database. To run the tests:
.. code-block:: bash
- $ git clone https://github.com:django/django.git django-repo
+ $ git clone https://github.com/django/django.git django-repo
$ cd django-repo/tests
$ PYTHONPATH=..:$PYTHONPATH ./runtests.py
diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt
index dc70aa3..9739274 100644
--- a/docs/internals/howto-release-django.txt
+++ b/docs/internals/howto-release-django.txt
@@ -87,7 +87,8 @@ any time leading up to the actual release:
the release. We maintain a list of who gets these pre-notification emails in
the private ``django-core`` repository. This email should be signed by the
key you'll use for the release, and should include patches for each issue
- being fixed.
+ being fixed. Also make sure to update the security issues archive; this will
+ be in ``docs/releases/security.txt``.
#. If this is a major release, make sure the tests pass, then increase
the default PBKDF2 iterations in
diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index 1641ed2..dcddf86 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -641,7 +641,7 @@ Once you're in the shell, explore the :doc:`database API </topics/db/queries>`::
>>> q.id
1
- # Access database columns via Python attributes.
+ # Access model field values via Python attributes.
>>> q.question_text
"What's new?"
>>> q.pub_date
diff --git a/docs/ref/class-based-views/generic-date-based.txt b/docs/ref/class-based-views/generic-date-based.txt
index bf70f23..c772443 100644
--- a/docs/ref/class-based-views/generic-date-based.txt
+++ b/docs/ref/class-based-views/generic-date-based.txt
@@ -63,7 +63,7 @@ ArchiveIndexView
month or day using the attribute ``date_list_period``. This also applies
to all subclass views.
- **Example myapp/views.py**::
+ **Example myapp/urls.py**::
from django.conf.urls import patterns, url
from django.views.generic.dates import ArchiveIndexView
diff --git a/docs/ref/class-based-views/index.txt b/docs/ref/class-based-views/index.txt
index a757e48..7962a81 100644
--- a/docs/ref/class-based-views/index.txt
+++ b/docs/ref/class-based-views/index.txt
@@ -1,6 +1,6 @@
-=====================
-Class-based views API
-=====================
+==============================
+Built-in Class-based views API
+==============================
Class-based views API reference. For introductory material, see
:doc:`/topics/class-based-views/index`.
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index 413b9ee..51b9ad9 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -2512,6 +2512,7 @@ own ``AdminSite`` instance since you will likely be importing all the per-app
put ``'django.contrib.admin.apps.SimpleAdminConfig'`` instead of
``'django.contrib.admin'`` in your :setting:`INSTALLED_APPS` setting.
+.. _multiple-admin-sites:
Multiple admin sites in the same URLconf
----------------------------------------
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 556f2cb..568339a 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -19,7 +19,8 @@ The sites framework is mainly based on a simple model:
A model for storing the ``domain`` and ``name`` attributes of a Web site.
The :setting:`SITE_ID` setting specifies the database ID of the
- :class:`~django.contrib.sites.models.Site` object associated with that
+ :class:`~django.contrib.sites.models.Site` object (accessible using
+ the automatically added ``id`` attribute) associated with that
particular settings file.
.. attribute:: domain
@@ -271,6 +272,11 @@ will also be created after Django creates the test database. To set the
correct name and domain for your project, you can use a :ref:`data migration
<data-migrations>`.
+In order to serve different sites in production, you'd create a separate
+settings file with each ``SITE_ID`` (perhaps importing from a common settings
+file to avoid duplicating shared settings) and then specify the appropriate
+:envvar:`DJANGO_SETTINGS_MODULE` for each site.
+
Caching the current ``Site`` object
===================================
diff --git a/docs/ref/contrib/staticfiles.txt b/docs/ref/contrib/staticfiles.txt
index 961abf5..c24c8fc 100644
--- a/docs/ref/contrib/staticfiles.txt
+++ b/docs/ref/contrib/staticfiles.txt
@@ -487,7 +487,7 @@ files in app directories.
Specialized test case to support 'live testing'
-----------------------------------------------
-.. class:: testing.StaticLiveServerCase
+.. class:: testing.StaticLiveServerTestCase
This unittest TestCase subclass extends :class:`django.test.LiveServerTestCase`.
@@ -504,5 +504,5 @@ transparently overlay at test execution-time the assets provided by the
.. versionadded:: 1.7
- ``StaticLiveServerCase`` is new in Django 1.7. Previously its functionality
- was provided by :class:`django.test.LiveServerTestCase`.
+ ``StaticLiveServerTestCase`` is new in Django 1.7. Previously its
+ functionality was provided by :class:`django.test.LiveServerTestCase`.
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index f03d9c3..dde56a3 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -525,6 +525,15 @@ respectively, a ``ValueError`` is raised rather than truncating data.
MySQL does not store fractions of seconds. Fractions of seconds are truncated
to zero when the time is stored.
+``TIMESTAMP`` columns
+~~~~~~~~~~~~~~~~~~~~~
+
+If you are using a legacy database that contains ``TIMESTAMP`` columns, you must
+set :setting:`USE_TZ = False <USE_TZ>` to avoid data corruption.
+:djadmin:`inspectdb` maps these columns to
+:class:`~django.db.models.DateTimeField` and if you enable timezone support,
+both MySQL and Django will attempt to convert the values from UTC to local time.
+
Row locking with ``QuerySet.select_for_update()``
-------------------------------------------------
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index a1ac811..3ebe229 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -695,6 +695,9 @@ Unlike ``syncdb``, this command does not prompt you to create a superuser if
one doesn't exist (assuming you are using :mod:`django.contrib.auth`). Use
:djadmin:`createsuperuser` to do that if you wish.
+The :djadminopt:`--database` option can be used to specify the database to
+migrate.
+
.. django-admin-option:: --fake
The ``--fake`` option tells Django to mark the migrations as having been
diff --git a/docs/ref/files/storage.txt b/docs/ref/files/storage.txt
index 3200ec3..f2578e7 100644
--- a/docs/ref/files/storage.txt
+++ b/docs/ref/files/storage.txt
@@ -119,7 +119,7 @@ The Storage Class
extension.
Previously, an underscore followed by a number (e.g. ``"_1"``, ``"_2"``,
- etc.) was appended to the filename until an avaible name in the
+ etc.) was appended to the filename until an available name in the
destination directory was found. A malicious user could exploit this
deterministic algorithm to create a denial-of-service attack. This
change was also made in Django 1.6.6, 1.5.9, and 1.4.14.
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index b584750..0bcbe6c 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -1003,6 +1003,17 @@ model object (in the case of ``ModelChoiceField``) or multiple model
objects (in the case of ``ModelMultipleChoiceField``) into the
``cleaned_data`` dictionary of the form.
+For more complex uses, you can specify ``queryset=None`` when declaring the
+form field and then populate the ``queryset`` in the form's ``__init__()``
+method::
+
+ class FooMultipleChoiceForm(forms.Form):
+ foo_select = forms.ModelMultipleChoiceField(queryset=None)
+
+ def __init__(self, *args, **kwargs):
+ super(FooMultipleChoiceForm, self).__init__(*args, **kwargs)
+ self.fields['foo_select'].queryset = ...
+
``ModelChoiceField``
~~~~~~~~~~~~~~~~~~~~
@@ -1050,8 +1061,10 @@ objects (in the case of ``ModelMultipleChoiceField``) into the
.. attribute:: to_field_name
This optional argument is used to specify the field to use as the value
- of the choices in the field's widget. By default it is set to ``None``,
- in which case the primary key of each object will be used. For example::
+ of the choices in the field's widget. Be sure it's a unique field for
+ the model, otherwise the selected value could match more than one
+ object. By default it is set to ``None``, in which case the primary key
+ of each object will be used. For example::
# No custom to_field_name
field1 = forms.ModelChoiceField(queryset=...)
diff --git a/docs/ref/forms/validation.txt b/docs/ref/forms/validation.txt
index 54655ef..ea74adb 100644
--- a/docs/ref/forms/validation.txt
+++ b/docs/ref/forms/validation.txt
@@ -100,7 +100,7 @@ These methods are run in the order given above, one field at a time. That is,
for each field in the form (in the order they are declared in the form
definition), the ``Field.clean()`` method (or its override) is run, then
``clean_<fieldname>()``. Finally, once those two methods are run for every
-field, the `:meth:`Form.clean()` method, or its override, is executed whether
+field, the :meth:`Form.clean()` method, or its override, is executed whether
or not the previous methods have raised errors.
Examples of each of these methods are provided below.
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
index e596339..45f5d83 100644
--- a/docs/ref/forms/widgets.txt
+++ b/docs/ref/forms/widgets.txt
@@ -217,7 +217,12 @@ foundation for custom widgets.
.. method:: value_from_datadict(data, files, name)
Given a dictionary of data and this widget's name, returns the value
- of this widget. Returns ``None`` if a value wasn't provided.
+ of this widget. ``files`` may contain data coming from
+ :attr:`request.FILES <django.http.HttpRequest.FILES>`. Returns ``None``
+ if a value wasn't provided. Note also that ``value_from_datadict`` may
+ be called more than once during handling of form data, so if you
+ customize it and add expensive processing, you should implement some
+ caching mechanism yourself.
.. class:: MultiWidget(widgets, attrs=None)
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 922a5d3..c99f717 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -1173,7 +1173,7 @@ define the details of how the relation works.
name = models.CharField(max_length=255)
# That's now the name of the reverse filter
- article_instance.filter(tag__name="important")
+ Article.objects.filter(tag__name="important")
.. attribute:: ForeignKey.to_field
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 73e1d18..208f271 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -1272,7 +1272,10 @@ Default::
("django.core.files.uploadhandler.MemoryFileUploadHandler",
"django.core.files.uploadhandler.TemporaryFileUploadHandler")
-A tuple of handlers to use for uploading. See :doc:`/topics/files` for details.
+A tuple of handlers to use for uploading. Changing this setting allows complete
+customization -- even replacement -- of Django's upload process.
+
+See :doc:`/topics/files` for details.
.. setting:: FILE_UPLOAD_MAX_MEMORY_SIZE
@@ -1319,6 +1322,9 @@ dependent behavior. On most platforms, temporary files will have a mode
of ``0o600``, and files saved from memory will be saved using the
system's standard umask.
+For security reasons, these permissions aren't applied to the temporary files
+that are stored in :setting:`FILE_UPLOAD_TEMP_DIR`.
+
This setting also determines the default permissions for collected static files
when using the :djadmin:`collectstatic` management command. See
:djadmin:`collectstatic` for details on overriding it.
@@ -1332,7 +1338,6 @@ when using the :djadmin:`collectstatic` management command. See
way that modes must be specified. If you try to use ``644``, you'll
get totally incorrect behavior.
-
.. setting:: FILE_UPLOAD_TEMP_DIR
FILE_UPLOAD_TEMP_DIR
@@ -1340,9 +1345,11 @@ FILE_UPLOAD_TEMP_DIR
Default: ``None``
-The directory to store data temporarily while uploading files. If ``None``,
-Django will use the standard temporary directory for the operating system. For
-example, this will default to '/tmp' on \*nix-style operating systems.
+The directory to store data (typically files larger than
+:setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`) temporarily while uploading files.
+If ``None``, Django will use the standard temporary directory for the operating
+system. For example, this will default to ``/tmp`` on \*nix-style operating
+systems.
See :doc:`/topics/files` for details.
@@ -3045,6 +3052,8 @@ Error reporting
* :setting:`SEND_BROKEN_LINK_EMAILS`
* :setting:`SILENCED_SYSTEM_CHECKS`
+.. _file-upload-settings:
+
File uploads
------------
* :setting:`DEFAULT_FILE_STORAGE`
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index 30a9e9b..ee1b490 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -280,6 +280,8 @@ like this::
If we connected a handler like this::
+ from django.db.models.signals import m2m_changed
+
def toppings_changed(sender, **kwargs):
# Do something
pass
@@ -449,7 +451,7 @@ Arguments sent with this signal:
For example, the :mod:`django.contrib.auth` app only prompts to create a
superuser when ``interactive`` is ``True``.
-``using``
+``db``
The alias of database on which a command will operate.
post_migrate
@@ -490,7 +492,7 @@ Arguments sent with this signal:
For example, the :mod:`django.contrib.auth` app only prompts to create a
superuser when ``interactive`` is ``True``.
-``db``
+``using``
The database alias used for synchronization. Defaults to the ``default``
database.
diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
index 0a50e5e..2c8abe2 100644
--- a/docs/ref/templates/api.txt
+++ b/docs/ref/templates/api.txt
@@ -274,6 +274,31 @@ Builtin variables
Every context contains ``True``, ``False`` and ``None``. As you would expect,
these variables resolve to the corresponding Python objects.
+Limitations with string literals
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Django's template language has no way to escape the characters used for its own
+syntax. For example, the :ttag:`templatetag` tag is required if you need to
+output character sequences like ``{%`` and ``%}``.
+
+A similar issue exists if you want to include these sequences in template filter
+or tag arguments. For example, when parsing a block tag, Django's template
+parser looks for the first occurrence of ``%}`` after a ``{%``. This prevents
+the use of ``"%}"`` as a string literal. For example, a ``TemplateSyntaxError``
+will be raised for the following expressions::
+
+ {% include "template.html" tvar="Some string literal with %} in it." %}
+
+ {% with tvar="Some string literal with %} in it." %}{% endwith %}
+
+The same issue can be triggered by using a reserved sequence in filter
+arguments::
+
+ {{ some.variable|default:"}}" }}
+
+If you need to use strings with these sequences, store them in template
+variables or use a custom template tag or filter to workaround the limitation.
+
Playing with Context objects
----------------------------
diff --git a/docs/releases/1.4.14.txt b/docs/releases/1.4.14.txt
index 98de8b0..d5d1a66 100644
--- a/docs/releases/1.4.14.txt
+++ b/docs/releases/1.4.14.txt
@@ -2,7 +2,7 @@
Django 1.4.14 release notes
===========================
-*Under development*
+*August 20, 2014*
Django 1.4.14 fixes several security issues in 1.4.13.
diff --git a/docs/releases/1.4.15.txt b/docs/releases/1.4.15.txt
new file mode 100644
index 0000000..e9498e8
--- /dev/null
+++ b/docs/releases/1.4.15.txt
@@ -0,0 +1,13 @@
+===========================
+Django 1.4.15 release notes
+===========================
+
+*Under development*
+
+Django 1.4.15 fixes a regression in the 1.4.14 security release.
+
+Bugfixes
+========
+
+* Allowed inherited and m2m fields to be referenced in the admin
+ (`#22486 <http://code.djangoproject.com/ticket/23329>`_)
diff --git a/docs/releases/1.5.10.txt b/docs/releases/1.5.10.txt
new file mode 100644
index 0000000..e247214
--- /dev/null
+++ b/docs/releases/1.5.10.txt
@@ -0,0 +1,13 @@
+===========================
+Django 1.5.10 release notes
+===========================
+
+*Under development*
+
+Django 1.5.10 fixes a regression in the 1.5.9 security release.
+
+Bugfixes
+========
+
+* Allowed inherited and m2m fields to be referenced in the admin
+ (`#22486 <http://code.djangoproject.com/ticket/23329>`_)
diff --git a/docs/releases/1.5.9.txt b/docs/releases/1.5.9.txt
index 5b91de0..9942ba0 100644
--- a/docs/releases/1.5.9.txt
+++ b/docs/releases/1.5.9.txt
@@ -2,7 +2,7 @@
Django 1.5.9 release notes
==========================
-*Under development*
+*August 20, 2014*
Django 1.5.9 fixes several security issues in 1.5.8.
diff --git a/docs/releases/1.6.6.txt b/docs/releases/1.6.6.txt
index 63a1537..6081cbc 100644
--- a/docs/releases/1.6.6.txt
+++ b/docs/releases/1.6.6.txt
@@ -2,7 +2,7 @@
Django 1.6.6 release notes
==========================
-*Under development*
+*August 20, 2014*
Django 1.6.6 fixes several security issues and bugs in 1.6.5.
diff --git a/docs/releases/1.6.7.txt b/docs/releases/1.6.7.txt
new file mode 100644
index 0000000..479a0b9
--- /dev/null
+++ b/docs/releases/1.6.7.txt
@@ -0,0 +1,16 @@
+==========================
+Django 1.6.7 release notes
+==========================
+
+*Under development*
+
+Django 1.6.7 fixes several bugs in 1.6.6, including a regression related to
+a security fix in that release.
+
+Bugfixes
+========
+
+* Allowed inherited and m2m fields to be referenced in the admin
+ (:ticket:`23329`).
+* Fixed a crash when using ``QuerySet.defer()`` with ``select_related()``
+ (:ticket:`23370`).
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index fd35725..c325754 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -1,6 +1,8 @@
-============================================
-Django 1.7 release notes - UNDER DEVELOPMENT
-============================================
+========================
+Django 1.7 release notes
+========================
+
+*September 2, 2014*
Welcome to Django 1.7!
@@ -51,11 +53,11 @@ but a few of the key features are:
to your models and make migrations for them.
:data:`~django.db.models.signals.pre_syncdb` and
- :data:`~django.db.models.signals.post_syncdb` have been replaced by
- :data:`~django.db.models.signals.pre_migrate` and
- :data:`~django.db.models.signals.post_migrate` respectively. These new
- signals have slightly different arguments. Check the documentation for
- details.
+ :data:`~django.db.models.signals.post_syncdb` have been deprecated,
+ to be replaced by :data:`~django.db.models.signals.pre_migrate` and
+ :data:`~django.db.models.signals.post_migrate` respectively. These
+ new signals have slightly different arguments. Check the
+ documentation for details.
* The ``allow_syncdb`` method on database routers is now called ``allow_migrate``,
but still performs the same function. Routers with ``allow_syncdb`` methods
@@ -123,8 +125,10 @@ Improvements thus far include:
New method on Field subclasses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To help power both schema migrations and composite keys, the :class:`~django.db.models.Field` API now
-has a new required method: ``deconstruct()``.
+To help power both schema migrations and to enable easier addition of
+composite keys in future releases of Django, the
+:class:`~django.db.models.Field` API now has a new required method:
+``deconstruct()``.
This method takes no arguments, and returns a tuple of four items:
@@ -255,10 +259,13 @@ specific backend's cursor defined the behavior of the context manager. The
behavior of magic method lookups was changed with Python 2.7 and cursors were
no longer usable as context managers.
-Django 1.7 allows a cursor to be used as a context manager that is a shortcut
-for the following, instead of backend specific behavior.
+Django 1.7 allows a cursor to be used as a context manager. That is,
+the following can be used::
+
+ with connection.cursor() as c:
+ c.execute(...)
-.. code-block:: python
+instead of::
c = connection.cursor()
try:
@@ -285,7 +292,7 @@ to ``DateField`` it is possible to filter on the transformed value, for
example ``qs.filter(author__birthdate__year__lte=1981)``.
For more information about both custom lookups and transforms refer to
-:doc:`custom lookups </howto/custom-lookups>` documentation.
+the :doc:`custom lookups </howto/custom-lookups>` documentation.
Improvements to ``Form`` error handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1341,7 +1348,7 @@ Miscellaneous
(similarly to what one gets with :setting:`DEBUG = True <DEBUG>` at
development-time) has been moved to a new class that lives in the
``staticfiles`` application (the one actually in charge of such feature):
- :class:`django.contrib.staticfiles.testing.StaticLiveServerCase`. In other
+ :class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase`. In other
words, ``LiveServerTestCase`` itself is less powerful but at the same time
has less magic.
diff --git a/docs/releases/index.txt b/docs/releases/index.txt
index 359820f..d57092d 100644
--- a/docs/releases/index.txt
+++ b/docs/releases/index.txt
@@ -32,6 +32,7 @@ versions of the documentation contain the release notes for any later releases.
.. toctree::
:maxdepth: 1
+ 1.6.7
1.6.6
1.6.5
1.6.4
@@ -45,6 +46,7 @@ versions of the documentation contain the release notes for any later releases.
.. toctree::
:maxdepth: 1
+ 1.5.10
1.5.9
1.5.8
1.5.7
@@ -61,6 +63,7 @@ versions of the documentation contain the release notes for any later releases.
.. toctree::
:maxdepth: 1
+ 1.4.15
1.4.14
1.4.13
1.4.12
diff --git a/docs/releases/security.txt b/docs/releases/security.txt
index c73cea6..d48d0b4 100644
--- a/docs/releases/security.txt
+++ b/docs/releases/security.txt
@@ -450,10 +450,10 @@ Versions affected
* Django 1.5 `(patch) <https://github.com/django/django/commit/22b74fa09d7ccbc8c52270d648a0da7f3f0fa2bc>`__
-April 21, 2014 - CVE-2014-2014-0472
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+April 21, 2014 - CVE-2014-0472
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-`CVE-2014-0472 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0472&cid=2>`_: Unexpected code execution using ``reverse()``. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`_
+`CVE-2014-0472 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0472&cid=2>`_: Unexpected code execution using ``reverse()``. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`__
Versions affected
-----------------
@@ -467,10 +467,10 @@ Versions affected
* Django 1.7 `(patch) <https://github.com/django/django/commit/546740544d7f69254a67b06a3fc7fa0c43512958>`__
-April 21, 2014 - CVE-2014-2014-0473
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+April 21, 2014 - CVE-2014-0473
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-`CVE-2014-0473 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0473&cid=2>`_: Caching of anonymous pages could reveal CSRF token. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`_
+`CVE-2014-0473 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0473&cid=2>`_: Caching of anonymous pages could reveal CSRF token. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`__
Versions affected
-----------------
@@ -484,10 +484,10 @@ Versions affected
* Django 1.7 `(patch) <https://github.com/django/django/commit/380545bf85cbf17fc698d136815b7691f8d023ca>`__
-April 21, 2014 - CVE-2014-2014-0474
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+April 21, 2014 - CVE-2014-0474
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-`CVE-2014-0474 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0474&cid=2>`_: MySQL typecasting causes unexpected query results. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`_
+`CVE-2014-0474 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0474&cid=2>`_: MySQL typecasting causes unexpected query results. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`__
Versions affected
-----------------
@@ -499,3 +499,105 @@ Versions affected
* Django 1.6 `(patch) <https://github.com/django/django/commit/5f0829a27e85d89ad8c433f5c6a7a7d17c9e9292>`__
* Django 1.7 `(patch) <https://github.com/django/django/commit/34526c2f56b863c2103655a0893ac801667e86ea>`__
+
+
+May 18, 2014 - CVE-2014-1418
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`CVE-2014-1418 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1418&cid=2>`_: Caches may be allowed to store and serve private data. `Full description <https://www.djangoproject.com/weblog/2014/may/14/security-releases-issued/>`__
+
+Versions affected
+-----------------
+
+* Django 1.4 `(patch) <https://github.com/django/django/commit/28e23306aa53bbbb8fb87db85f99d970b051026c>`__
+
+* Django 1.5 `(patch) <https://github.com/django/django/commit/4001ec8698f577b973c5a540801d8a0bbea1205b>`__
+
+* Django 1.6 `(patch) <https://github.com/django/django/commit/1abcf3a808b35abae5d425ed4d44cb6e886dc769>`__
+
+* Django 1.7 `(patch) <https://github.com/django/django/commit/7fef18ba9e5a8b47bc24b5bb259c8bf3d3879f2a>`__
+
+
+May 18, 2014 - CVE-2014-3730
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`CVE-2014-3730 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3730&cid=2>`_: Malformed URLs from user input incorrectly validated. `Full description <https://www.djangoproject.com/weblog/2014/may/14/security-releases-issued/>`__
+
+Versions affected
+-----------------
+
+* Django 1.4 `(patch) <https://github.com/django/django/commit/7feb54bbae3f637ab3c4dd4831d4385964f574df>`__
+
+* Django 1.5 `(patch) <https://github.com/django/django/commit/ad32c218850ad40972dcef57beb460f8c979dd6d>`__
+
+* Django 1.6 `(patch) <https://github.com/django/django/commit/601107524523bca02376a0ddc1a06c6fdb8f22f3>`__
+
+* Django 1.7 `(patch) <https://github.com/django/django/commit/e7b0cace455c2da24492660636bfd48c45a19cdf>`__
+
+
+August 20, 2014 - CVE-2014-0480
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`CVE-2014-0480 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0480&cid=2>`_: reverse() can generate URLs pointing to other hosts. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
+
+Versions affected
+-----------------
+
+* Django 1.4 `(patch) <https://github.com/django/django/commit/c2fe73133b62a1d9e8f7a6b43966570b14618d7e>`__
+
+* Django 1.5 `(patch) <https://github.com/django/django/commit/45ac9d4fb087d21902469fc22643f5201d41a0cd>`__
+
+* Django 1.6 `(patch) <https://github.com/django/django/commit/da051da8df5e69944745072611351d4cfc6435d5>`__
+
+* Django 1.7 `(patch) <https://github.com/django/django/commit/bf650a2ee78c6d1f4544a875dcc777cf27fe93e9>`__
+
+
+August 20, 2014 - CVE-2014-0481
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`CVE-2014-0481 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0481&cid=2>`_: File upload denial of service. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
+
+Versions affected
+-----------------
+
+* Django 1.4 `(patch) <https://github.com/django/django/commit/30042d475bf084c6723c6217a21598d9247a9c41>`__
+
+* Django 1.5 `(patch) <https://github.com/django/django/commit/26cd48e166ac4d84317c8ee6d63ac52a87e8da99>`__
+
+* Django 1.6 `(patch) <https://github.com/django/django/commit/dd0c3f4ee1a30c1a1e6055061c6ba6e58c6b54d1>`__
+
+* Django 1.7 `(patch) <https://github.com/django/django/commit/3123f8452cf49071be9110e277eea60ba0032216>`__
+
+
+August 20, 2014 - CVE-2014-0482
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`CVE-2014-0482 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0482&cid=2>`_: RemoteUserMiddleware session hijacking. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
+
+Versions affected
+-----------------
+
+* Django 1.4 `(patch) <https://github.com/django/django/commit/c9e3b9949cd55f090591fbdc4a114fcb8368b6d9>`__
+
+* Django 1.5 `(patch) <https://github.com/django/django/commit/dd68f319b365f6cb38c5a6c106faf4f6142d7d88>`__
+
+* Django 1.6 `(patch) <https://github.com/django/django/commit/0268b855f9eab3377f2821164ef3e66037789e09>`__
+
+* Django 1.7 `(patch) <https://github.com/django/django/commit/1a45d059c70385fcd6f4a3955f3b4e4cc96d0150>`__
+
+
+August 20, 2014 - CVE-2014-0483
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`CVE-2014-0483 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0483&cid=2>`_: Data leakage via querystring manipulation in admin. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
+
+Versions affected
+-----------------
+
+* Django 1.4 `(patch) <https://github.com/django/django/commit/027bd348642007617518379f8b02546abacaa6e0>`__
+
+* Django 1.5 `(patch) <https://github.com/django/django/commit/2a446c896e7c814661fb9c4f212b071b2a7fa446>`__
+
+* Django 1.6 `(patch) <https://github.com/django/django/commit/f7c494f2506250b8cb5923714360a3642ed63e0f>`__
+
+* Django 1.7 `(patch) <https://github.com/django/django/commit/2b31342cdf14fc20e07c43d258f1e7334ad664a6>`__
diff --git a/docs/topics/auth/index.txt b/docs/topics/auth/index.txt
index dffaa74..e588c39 100644
--- a/docs/topics/auth/index.txt
+++ b/docs/topics/auth/index.txt
@@ -68,9 +68,8 @@ and two items in your :setting:`MIDDLEWARE_CLASSES` setting:
users with requests using sessions.
With these settings in place, running the command ``manage.py migrate`` creates
-the necessary database tables for auth related models, creates permissions for
-any models defined in your installed apps, and prompts you to create
-a superuser account the first time you run it.
+the necessary database tables for auth related models and permissions for any
+models defined in your installed apps.
Usage
=====
diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt
index 9c5527d..be9df1d 100644
--- a/docs/topics/class-based-views/generic-display.txt
+++ b/docs/topics/class-based-views/generic-display.txt
@@ -1,8 +1,8 @@
.. _Generic views:
-=========================
-Class-based generic views
-=========================
+==================================
+Built-in Class-based generic views
+==================================
Writing Web applications can be monotonous, because we repeat certain patterns
again and again. Django tries to take away some of that monotony at the model
diff --git a/docs/topics/db/multi-db.txt b/docs/topics/db/multi-db.txt
index 470fe1c..6594f4c 100644
--- a/docs/topics/db/multi-db.txt
+++ b/docs/topics/db/multi-db.txt
@@ -47,8 +47,11 @@ If the concept of a ``default`` database doesn't make sense in the context
of your project, you need to be careful to always specify the database
that you want to use. Django requires that a ``default`` database entry
be defined, but the parameters dictionary can be left blank if it will not be
-used. The following is an example ``settings.py`` snippet defining two
-non-default databases, with the ``default`` entry intentionally left empty::
+used. You must setup :setting:`DATABASE_ROUTERS` for all of your apps' models,
+including those in any contrib and third-party apps you are using, so that no
+queries are routed to the default database in order to do this. The following
+is an example ``settings.py`` snippet defining two non-default databases, with
+the ``default`` entry intentionally left empty::
DATABASES = {
'default': {},
@@ -87,12 +90,6 @@ particular database, you can define a :ref:`database
router<topics-db-multi-db-routing>` that implements a policy
constraining the availability of particular models.
-Alternatively, if you want fine-grained control of synchronization,
-you can pipe all or part of the output of :djadmin:`sqlall` for a
-particular application directly into your database prompt, like this::
-
- $ ./manage.py sqlall sales | ./manage.py dbshell
-
Using other management commands
-------------------------------
@@ -690,12 +687,11 @@ In addition, some objects are automatically created just after
database).
For common setups with multiple databases, it isn't useful to have these
-objects in more than one database. Common setups include master / slave and
-connecting to external databases. Therefore, it's recommended:
-
-- either to run :djadmin:`migrate` only for the default database;
-- or to write :ref:`database router<topics-db-multi-db-routing>` that allows
- synchronizing these three models only to one database.
+objects in more than one database. Common setups include primary/replica and
+connecting to external databases. Therefore, it's recommended to write a
+:ref:`database router<topics-db-multi-db-routing>` that allows synchronizing
+these three models to only one database. Use the same approach for contrib
+and third-party apps that don't need their tables in multiple databases.
.. warning::
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index 857ffaa..49a0f15 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -345,6 +345,16 @@ from that ``{{ form }}`` by Django's template language.
directly tied to forms in templates, this tag is omitted from the
following examples in this document.
+.. admonition:: HTML5 input types and browser validation
+
+ If your form includes a :class:`~django.forms.URLField`, an
+ :class:`~django.forms.EmailField` or any integer field type, Django will
+ use the ``url``, ``email`` and ``number`` HTML5 input types. By default,
+ browsers may apply their own validation on these fields, which may be
+ stricter than Django's validation. If you would like to disable this
+ behavior, set the `novalidate` attribute on the ``form`` tag, or specify
+ a different widget on the field, like :class:`TextInput`.
+
We now have a working web form, described by a Django :class:`Form`, processed
by a view, and rendered as an HTML ``<form>``.
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index ec45665..c0bf8ba 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -168,53 +168,8 @@ defaults" which can be customized as described in the next section.
Changing upload handler behavior
--------------------------------
-There are a few settings which control Django's file upload behavior:
-
-:setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`
- The maximum size, in bytes, for files that will be uploaded into memory.
- Files larger than :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` will be
- streamed to disk.
-
- Defaults to 2.5 megabytes.
-
-:setting:`FILE_UPLOAD_TEMP_DIR`
- The directory where uploaded files larger than
- :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` will be stored.
-
- Defaults to your system's standard temporary directory (i.e. ``/tmp`` on
- most Unix-like systems).
-
-:setting:`FILE_UPLOAD_PERMISSIONS`
- The numeric mode (i.e. ``0o644``) to set newly uploaded files to. For
- more information about what these modes mean, see the documentation for
- :func:`os.chmod`.
-
- If this isn't given or is ``None``, you'll get operating-system
- dependent behavior. On most platforms, temporary files will have a mode
- of ``0o600``, and files saved from memory will be saved using the
- system's standard umask.
-
- For security reasons, these permissions aren't applied to the temporary
- files that are stored in :setting:`FILE_UPLOAD_TEMP_DIR`.
-
- .. warning::
-
- If you're not familiar with file modes, please note that the leading
- ``0`` is very important: it indicates an octal number, which is the
- way that modes must be specified. If you try to use ``644``, you'll
- get totally incorrect behavior.
-
- **Always prefix the mode with a 0.**
-
-:setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS`
- The numeric mode to apply to directories created in the process of
- uploading files. This value mirrors the functionality and caveats of
- the :setting:`FILE_UPLOAD_PERMISSIONS` setting.
-
-:setting:`FILE_UPLOAD_HANDLERS`
- The actual handlers for uploaded files. Changing this setting allows
- complete customization -- even replacement -- of Django's upload
- process.
+There are a few settings which control Django's file upload behavior. See
+:ref:`File Upload Settings <file-upload-settings>` for details.
Modifying upload handlers on the fly
------------------------------------
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index 2d52422..a306434 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -743,11 +743,21 @@ URL namespaces
Introduction
------------
-When you need to deploy multiple instances of a single application, it can be
-helpful to be able to differentiate between instances. This is especially
-important when using :ref:`named URL patterns <naming-url-patterns>`, since
-multiple instances of a single application will share named URLs. Namespaces
-provide a way to tell these named URLs apart.
+URL namespaces allow you to uniquely reverse :ref:`named URL patterns
+<naming-url-patterns>` even if different applications use the same URL names.
+It's a good practice for third-party apps to always use namespaced URLs (as we
+did in the tutorial). Similarly, it also allows you to reverse URLs if multiple
+instances of an application are deployed. In other words, since multiple
+instances of a single application will share named URLs, namespaces provide a
+way to tell these named URLs apart.
+
+Django applications that make proper use of URL namespacing can be deployed more
+than once for a particular site. For example :mod:`django.contrib.admin` has an
+:class:`~django.contrib.admin.AdminSite` class which allows you to easily
+:ref:`deploy more than once instance of the admin <multiple-admin-sites>`.
+In a later example, we'll discuss the idea of deploying the polls application
+from the tutorial in two different locations so we can serve the same
+functionality to two different audiences (authors and publishers).
A URL namespace comes in two parts, both of which are strings:
@@ -763,44 +773,43 @@ A URL namespace comes in two parts, both of which are strings:
This identifies a specific instance of an application. Instance namespaces
should be unique across your entire project. However, an instance namespace
can be the same as the application namespace. This is used to specify a
- default instance of an application. For example, the default Django Admin
+ default instance of an application. For example, the default Django admin
instance has an instance namespace of ``'admin'``.
Namespaced URLs are specified using the ``':'`` operator. For example, the main
index page of the admin application is referenced using ``'admin:index'``. This
indicates a namespace of ``'admin'``, and a named URL of ``'index'``.
-Namespaces can also be nested. The named URL ``'foo:bar:whiz'`` would look for
-a pattern named ``'whiz'`` in the namespace ``'bar'`` that is itself defined
-within the top-level namespace ``'foo'``.
+Namespaces can also be nested. The named URL ``'sports:polls:index'`` would
+look for a pattern named ``'index'`` in the namespace ``'polls'`` that is itself
+defined within the top-level namespace ``'sports'``.
.. _topics-http-reversing-url-namespaces:
Reversing namespaced URLs
-------------------------
-When given a namespaced URL (e.g. ``'myapp:index'``) to resolve, Django splits
-the fully qualified name into parts, and then tries the following lookup:
+When given a namespaced URL (e.g. ``'polls:index'``) to resolve, Django splits
+the fully qualified name into parts and then tries the following lookup:
1. First, Django looks for a matching :term:`application namespace` (in this
- example, ``'myapp'``). This will yield a list of instances of that
+ example, ``'polls'``). This will yield a list of instances of that
application.
2. If there is a *current* application defined, Django finds and returns
the URL resolver for that instance. The *current* application can be
specified as an attribute on the template context - applications that
expect to have multiple deployments should set the ``current_app``
- attribute on any ``Context`` or ``RequestContext`` that is used to
- render a template.
+ attribute on any :class:`~django.template.Context` or
+ :class:`~django.template.RequestContext` that is used to render a template.
The current application can also be specified manually as an argument
- to the :func:`django.core.urlresolvers.reverse` function.
+ to the :func:`~django.core.urlresolvers.reverse` function.
3. If there is no current application. Django looks for a default
application instance. The default application instance is the instance
that has an :term:`instance namespace` matching the :term:`application
- namespace` (in this example, an instance of the ``myapp`` called
- ``'myapp'``).
+ namespace` (in this example, an instance of ``polls`` called ``'polls'``).
4. If there is no default application instance, Django will pick the last
deployed instance of the application, whatever its instance name may be.
@@ -817,37 +826,73 @@ Example
~~~~~~~
To show this resolution strategy in action, consider an example of two instances
-of ``myapp``: one called ``'foo'``, and one called ``'bar'``. ``myapp`` has a
-main index page with a URL named ``'index'``. Using this setup, the following
-lookups are possible:
+of the ``polls`` application from the tutorial: one called ``'author-polls'``
+and one called ``'publisher-polls'``. Assume we have enhanced that application
+so that it takes the instance namespace into consideration when creating and
+displaying polls.
-* If one of the instances is current - say, if we were rendering a utility page
- in the instance ``'bar'`` - ``'myapp:index'`` will resolve to the index page
- of the instance ``'bar'``.
+.. snippet::
+ :filename: urls.py
-* If there is no current instance - say, if we were rendering a page
- somewhere else on the site - ``'myapp:index'`` will resolve to the last
- registered instance of ``myapp``. Since there is no default instance,
- the last instance of ``myapp`` that is registered will be used. This could
- be ``'foo'`` or ``'bar'``, depending on the order they are introduced into the
- urlpatterns of the project.
+ from django.conf.urls import include, url
+
+ urlpatterns = [
+ url(r'^author-polls/', include('polls.urls', namespace='author-polls', app_name='polls')),
+ url(r'^publisher-polls/', include('polls.urls', namespace='publisher-polls', app_name='polls')),
+ ]
+
+.. snippet::
+ :filename: polls/urls.py
+
+ from django.conf.urls import url
+
+ from . import views
+
+ urlpatterns = [
+ url(r'^$', views.IndexView.as_view(), name='index'),
+ url(r'^(?P<pk>\d+)/$', views.DetailView.as_view(), name='detail'),
+ ...
+ ]
+
+Using this setup, the following lookups are possible:
+
+* If one of the instances is current - say, if we were rendering the detail page
+ in the instance ``'author-polls'`` - ``'polls:index'`` will resolve to the
+ index page of the ``'author-polls'`` instance; i.e. both of the following will
+ result in ``"/author-polls/"``.
-* ``'foo:index'`` will always resolve to the index page of the instance
- ``'foo'``.
+ In the method of a class-based view::
-If there was also a default instance - i.e., an instance named ``'myapp'`` - the
-following would happen:
+ reverse('polls:index', current_app=self.request.resolver_match.namespace)
-* If one of the instances is current - say, if we were rendering a utility page
- in the instance ``'bar'`` - ``'myapp:index'`` will resolve to the index page
- of the instance ``'bar'``.
+ and in the template:
-* If there is no current instance - say, if we were rendering a page somewhere
- else on the site - ``'myapp:index'`` will resolve to the index page of the
- default instance.
+ .. code-block:: html+django
-* ``'foo:index'`` will again resolve to the index page of the instance
- ``'foo'``.
+ {% url 'polls:index' %}
+
+ Note that reversing in the template requires the ``current_app`` be added as
+ an attribute to the template context like this::
+
+ def render_to_response(self, context, **response_kwargs):
+ response_kwargs['current_app'] = self.request.resolver_match.namespace
+ return super(DetailView, self).render_to_response(context, **response_kwargs)
+
+* If there is no current instance - say, if we were rendering a page
+ somewhere else on the site - ``'polls:index'`` will resolve to the last
+ registered instance of ``polls``. Since there is no default instance
+ (instance namespace of ``'polls'``), the last instance of ``polls`` that is
+ registered will be used. This would be ``'publisher-polls'`` since it's
+ declared last in the ``urlpatterns``.
+
+* ``'author-polls:index'`` will always resolve to the index page of the instance
+ ``'author-polls'`` (and likewise for ``'publisher-polls'``) .
+
+If there were also a default instance - i.e., an instance named ``'polls'`` -
+the only change from above would be in the case where there is no current
+instance (the second item in the list above). In this case ``'polls:index'``
+would resolve to the index page of the default instance instead of the instance
+declared last in ``urlpatterns``.
.. _namespaces-and-include:
@@ -858,17 +903,17 @@ URL namespaces of included URLconfs can be specified in two ways.
Firstly, you can provide the :term:`application <application namespace>` and
:term:`instance <instance namespace>` namespaces as arguments to
-:func:`django.conf.urls.include()` when you construct your URL patterns. For
+:func:`~django.conf.urls.include()` when you construct your URL patterns. For
example,::
- url(r'^help/', include('apps.help.urls', namespace='foo', app_name='bar')),
+ url(r'^polls/', include('polls.urls', namespace='author-polls', app_name='polls')),
-This will include the URLs defined in ``apps.help.urls`` into the
-:term:`application namespace` ``'bar'``, with the :term:`instance namespace`
-``'foo'``.
+This will include the URLs defined in ``polls.urls`` into the
+:term:`application namespace` ``'polls'``, with the :term:`instance namespace`
+``'author-polls'``.
Secondly, you can include an object that contains embedded namespace data. If
-you ``include()`` an object as returned by :func:`~django.conf.urls.patterns`,
+you ``include()`` a list of :func:`~django.conf.urls.url` instances,
the URLs contained in that object will be added to the global namespace.
However, you can also ``include()`` a 3-tuple containing::
@@ -876,28 +921,29 @@ However, you can also ``include()`` a 3-tuple containing::
For example::
- from django.conf.urls import include, patterns, url
+ from django.conf.urls import include, url
- from app.helps import views
+ from . import views
- help_patterns = patterns('',
- url(r'^basic/$', views.views.basic),
- url(r'^advanced/$', views.views.advanced),
- )
+ polls_patterns = [
+ url(r'^$', views.IndexView.as_view(), name='index'),
+ url(r'^(?P<pk>\d+)/$', views.DetailView.as_view(), name='detail'),
+ ]
- url(r'^help/', include((help_patterns, 'bar', 'foo'))),
+ url(r'^polls/', include((polls_patterns, 'polls', 'author-polls'))),
This will include the nominated URL patterns into the given application and
instance namespace.
-For example, the Django Admin is deployed as instances of
+For example, the Django admin is deployed as instances of
:class:`~django.contrib.admin.AdminSite`. ``AdminSite`` objects have a ``urls``
attribute: A 3-tuple that contains all the patterns in the corresponding admin
site, plus the application namespace ``'admin'``, and the name of the admin
instance. It is this ``urls`` attribute that you ``include()`` into your
-projects ``urlpatterns`` when you deploy an Admin instance.
+projects ``urlpatterns`` when you deploy an admin instance.
Be sure to pass a tuple to ``include()``. If you simply pass three arguments:
-``include(help_patterns, 'bar', 'foo')``, Django won't throw an error but due
-to the signature of ``include()``, ``'bar'`` will be the instance namespace and
-``'foo'`` will be the application namespace instead of vice versa.
+``include(polls_patterns, 'polls', 'author-polls')``, Django won't throw an
+error but due to the signature of ``include()``, ``'polls'`` will be the
+instance namespace and ``'author-polls'`` will be the application namespace
+instead of vice versa.
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index ddb161d..7baa673 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -102,7 +102,8 @@ should be aware too. In this mode, the example above becomes::
lead to questionable usefulness".
Django only supports naive time objects and will raise an exception if you
- attempt to save an aware time object.
+ attempt to save an aware time object, as a timezone for a time with no
+ associated date does not make sense.
.. _naive-datetime-objects:
diff --git a/docs/topics/i18n/translation.txt b/docs/topics/i18n/translation.txt
index ed0bdb9..71b93aa 100644
--- a/docs/topics/i18n/translation.txt
+++ b/docs/topics/i18n/translation.txt
@@ -1253,10 +1253,9 @@ To create or update a message file, run this command::
django-admin.py makemessages -l de
-...where ``de`` is the language code for the message file you want to create.
-The language code, in this case, is in :term:`locale format<locale name>`. For
-example, it's ``pt_BR`` for Brazilian Portuguese and ``de_AT`` for Austrian
-German.
+...where ``de`` is the :term:`locale name` for the message file you want to
+create. For example, ``pt_BR`` for Brazilian Portuguese, ``de_AT`` for Austrian
+German or ``id`` for Indonesian.
The script should be run from one of two places:
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
old mode 100644
new mode 100755
index 0aad1a5..f08669a
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -331,6 +331,10 @@ They will, however, have the same fields, relationships and ``Meta`` options
when you access them in migrations, and you will NOT have any custom
constructors or instance methods. Plan appropriately!
+References to functions in field options such as ``upload_to`` and
+``limit_choices_to`` are serialized in migrations, so the functions will need
+to be kept around for as long as there is a migration referencing them.
+
In addition, the base classes of the model are just stored as pointers,
so you must always keep base classes around for as long as there is a migration
that contains a reference to them. On the plus side, methods and managers
@@ -483,11 +487,16 @@ work::
you can delete them.
Note that model interdependencies in Django can get very complex, and squashing
-may occasionally result in an optimized migration that doesn't work or is
-impossible to run. When this occurs, you can re-try with ``--no-optimize``, but
-please `file a bug report <https://code.djangoproject.com/newticket>`_ either
-way detailing the models and their relationships so we can improve the
-optimizer to handle your case.
+may result in migrations that do not run; either mis-optimized (in which case
+you can try again with ``--no-optimize``, though you should also report an issue),
+or with a ``CircularDependencyError``, in which case you can manually resolve it.
+
+To manually resolve a ``CircularDependencyError``, break out one of
+the ForeignKeys in the circular dependency loop into a separate
+migration, and move the dependency on the other app with it. If you're unsure,
+see how makemigrations deals with the problem when asked to create brand
+new migrations from your models. In a future release of Django, squashmigrations
+will be updated to attempt to resolve these errors itself.
Once you've squashed your migration, you should then commit it alongside the
migrations it replaces and distribute this change to all running instances
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 680e6ac..9f4329c 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -773,9 +773,9 @@ out the `full reference`_ for more details.
If you use the ``staticfiles`` app in your project and need to perform live
testing then you might want to consider using the
- :class:`~django.contrib.staticfiles.testing.StaticLiveServerCase` subclass
- shipped with it instead because it's the one that implements the original
- behavior now. See :ref:`the relevant documentation
+ :class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
+ subclass shipped with it instead because it's the one that implements the
+ original behavior now. See :ref:`the relevant documentation
<staticfiles-testing-support>` for more details.
.. note::
diff --git a/tests/admin_views/admin.py b/tests/admin_views/admin.py
index cb72d1b..8897e27 100644
--- a/tests/admin_views/admin.py
+++ b/tests/admin_views/admin.py
@@ -35,7 +35,8 @@ from .models import (Article, Chapter, Child, Parent, Picture, Widget,
UnchangeableObject, UserMessenger, Simple, Choice, ShortMessage, Telegram,
FilteredManager, EmptyModelHidden, EmptyModelVisible, EmptyModelMixin,
State, City, Restaurant, Worker, ParentWithDependentChildren,
- DependentChild, StumpJoke, FieldOverridePost, FunkyTag)
+ DependentChild, StumpJoke, FieldOverridePost, FunkyTag,
+ ReferencedByParent, ChildOfReferer, M2MReference)
def callable_year(dt_value):
@@ -881,6 +882,9 @@ site.register(City, CityAdmin)
site.register(Restaurant, RestaurantAdmin)
site.register(Worker, WorkerAdmin)
site.register(FunkyTag, FunkyTagAdmin)
+site.register(ReferencedByParent)
+site.register(ChildOfReferer)
+site.register(M2MReference)
# We intentionally register Promo and ChapterXtra1 but not Chapter nor ChapterXtra2.
# That way we cover all four cases:
diff --git a/tests/admin_views/models.py b/tests/admin_views/models.py
index fb72b12..413201c 100644
--- a/tests/admin_views/models.py
+++ b/tests/admin_views/models.py
@@ -822,3 +822,20 @@ class Worker(models.Model):
work_at = models.ForeignKey(Restaurant)
name = models.CharField(max_length=50)
surname = models.CharField(max_length=50)
+
+
+# Models for #23329
+class ReferencedByParent(models.Model):
+ pass
+
+
+class ParentWithFK(models.Model):
+ fk = models.ForeignKey(ReferencedByParent)
+
+
+class ChildOfReferer(ParentWithFK):
+ pass
+
+
+class M2MReference(models.Model):
+ ref = models.ManyToManyField('self')
diff --git a/tests/admin_views/tests.py b/tests/admin_views/tests.py
index cf5d22e..03a2974 100644
--- a/tests/admin_views/tests.py
+++ b/tests/admin_views/tests.py
@@ -617,6 +617,15 @@ class AdminViewBasicTest(AdminViewBasicTestCase):
response = self.client.get("/test_admin/admin/admin_views/section/", {TO_FIELD_VAR: 'id'})
self.assertEqual(response.status_code, 200)
+ # Specifying a field referenced by another model though a m2m should be allowed.
+ response = self.client.get("/test_admin/admin/admin_views/m2mreference/", {TO_FIELD_VAR: 'id'})
+ self.assertEqual(response.status_code, 200)
+
+ # Specifying a field that is not refered by any other model directly registered
+ # to this admin site but registered through inheritance should be allowed.
+ response = self.client.get("/test_admin/admin/admin_views/referencedbyparent/", {TO_FIELD_VAR: 'id'})
+ self.assertEqual(response.status_code, 200)
+
# We also want to prevent the add and change view from leaking a
# disallowed field value.
with patch_logger('django.security.DisallowedModelAdminToField', 'error') as calls:
diff --git a/tests/apps/tests.py b/tests/apps/tests.py
index 777e26d..2c7629a 100644
--- a/tests/apps/tests.py
+++ b/tests/apps/tests.py
@@ -1,4 +1,4 @@
-from __future__ import absolute_import, unicode_literals
+from __future__ import unicode_literals
import os
import sys
diff --git a/tests/commands_sql/tests.py b/tests/commands_sql/tests.py
index 8360648..3d9e234 100644
--- a/tests/commands_sql/tests.py
+++ b/tests/commands_sql/tests.py
@@ -1,5 +1,7 @@
from __future__ import unicode_literals
+import re
+
from django.apps import apps
from django.core.management.color import no_style
from django.core.management.sql import (sql_create, sql_delete, sql_indexes,
@@ -19,11 +21,27 @@ class SQLCommandsTestCase(TestCase):
def test_sql_create(self):
app_config = apps.get_app_config('commands_sql')
output = sql_create(app_config, no_style(), connections[DEFAULT_DB_ALIAS])
- create_tables = [o for o in output if o.startswith('CREATE TABLE')]
- self.assertEqual(len(create_tables), 3)
- # Lower so that Oracle's upper case tbl names wont break
- sql = create_tables[-1].lower()
- six.assertRegex(self, sql, r'^create table .commands_sql_book.*')
+
+ tables = set()
+ create_table_re = re.compile(r'^create table .(?P<table>[\w_]+).*', re.IGNORECASE)
+ reference_re = re.compile(r'.* references .(?P<table>[\w_]+).*', re.IGNORECASE)
+ for statement in output:
+ create_table = create_table_re.match(statement)
+ if create_table:
+ # Lower since Oracle's table names are upper cased.
+ tables.add(create_table.group('table').lower())
+ continue
+ reference = reference_re.match(statement)
+ if reference:
+ # Lower since Oracle's table names are upper cased.
+ table = reference.group('table').lower()
+ self.assertIn(
+ table, tables, "The table %s is referenced before its creation." % table
+ )
+
+ self.assertEqual(tables, {
+ 'commands_sql_comment', 'commands_sql_book', 'commands_sql_book_comments'
+ })
def test_sql_delete(self):
app_config = apps.get_app_config('commands_sql')
diff --git a/tests/contenttypes_tests/tests.py b/tests/contenttypes_tests/tests.py
index a54fb5c..6d4721d 100644
--- a/tests/contenttypes_tests/tests.py
+++ b/tests/contenttypes_tests/tests.py
@@ -1,5 +1,5 @@
# -*- coding: utf-8 -*-
-from __future__ import absolute_import, unicode_literals
+from __future__ import unicode_literals
import sys
diff --git a/tests/i18n/tests.py b/tests/i18n/tests.py
index 9edcec4..e4bae85 100644
--- a/tests/i18n/tests.py
+++ b/tests/i18n/tests.py
@@ -154,6 +154,17 @@ class TranslationTests(TestCase):
with six.assertRaisesRegex(self, KeyError, 'Your dictionary lacks key.*'):
complex_context_deferred % {'name': 'Jim'}
+ @skipUnless(six.PY2, "PY3 doesn't have distinct int and long types")
+ def test_ungettext_lazy_long(self):
+ """
+ Regression test for #22820: int and long should be treated alike in ungettext_lazy.
+ """
+ result = ungettext_lazy('%(name)s has %(num)d good result', '%(name)s has %(num)d good results', 4)
+ self.assertEqual(result % {'name': 'Joe', 'num': 4}, "Joe has 4 good results")
+ # Now with a long
+ result = ungettext_lazy('%(name)s has %(num)d good result', '%(name)s has %(num)d good results', long(4))
+ self.assertEqual(result % {'name': 'Joe', 'num': 4}, "Joe has 4 good results")
+
@override_settings(LOCALE_PATHS=extended_locale_paths)
def test_pgettext(self):
trans_real._active = local()
diff --git a/tests/migrations/test_autodetector.py b/tests/migrations/test_autodetector.py
index 3cfba95..9c1d8c5 100644
--- a/tests/migrations/test_autodetector.py
+++ b/tests/migrations/test_autodetector.py
@@ -154,8 +154,8 @@ class AutodetectorTests(TestCase):
graph.add_node(("testapp", "0001_initial"), None)
graph.add_node(("testapp", "0002_foobar"), None)
graph.add_node(("otherapp", "0001_initial"), None)
- graph.add_dependency(("testapp", "0002_foobar"), ("testapp", "0001_initial"))
- graph.add_dependency(("testapp", "0002_foobar"), ("otherapp", "0001_initial"))
+ graph.add_dependency("testapp.0002_foobar", ("testapp", "0002_foobar"), ("testapp", "0001_initial"))
+ graph.add_dependency("testapp.0002_foobar", ("testapp", "0002_foobar"), ("otherapp", "0001_initial"))
# Use project state to make a new migration change set
before = self.make_project_state([])
after = self.make_project_state([self.author_empty, self.other_pony, self.other_stable])
diff --git a/tests/migrations/test_graph.py b/tests/migrations/test_graph.py
index b6a7c62..ada8a5a 100644
--- a/tests/migrations/test_graph.py
+++ b/tests/migrations/test_graph.py
@@ -23,11 +23,11 @@ class GraphTests(TestCase):
graph.add_node(("app_a", "0004"), None)
graph.add_node(("app_b", "0001"), None)
graph.add_node(("app_b", "0002"), None)
- graph.add_dependency(("app_a", "0004"), ("app_a", "0003"))
- graph.add_dependency(("app_a", "0003"), ("app_a", "0002"))
- graph.add_dependency(("app_a", "0002"), ("app_a", "0001"))
- graph.add_dependency(("app_a", "0003"), ("app_b", "0002"))
- graph.add_dependency(("app_b", "0002"), ("app_b", "0001"))
+ graph.add_dependency("app_a.0004", ("app_a", "0004"), ("app_a", "0003"))
+ graph.add_dependency("app_a.0003", ("app_a", "0003"), ("app_a", "0002"))
+ graph.add_dependency("app_a.0002", ("app_a", "0002"), ("app_a", "0001"))
+ graph.add_dependency("app_a.0003", ("app_a", "0003"), ("app_b", "0002"))
+ graph.add_dependency("app_b.0002", ("app_b", "0002"), ("app_b", "0001"))
# Test root migration case
self.assertEqual(
graph.forwards_plan(("app_a", "0001")),
@@ -78,15 +78,15 @@ class GraphTests(TestCase):
graph.add_node(("app_b", "0002"), None)
graph.add_node(("app_c", "0001"), None)
graph.add_node(("app_c", "0002"), None)
- graph.add_dependency(("app_a", "0004"), ("app_a", "0003"))
- graph.add_dependency(("app_a", "0003"), ("app_a", "0002"))
- graph.add_dependency(("app_a", "0002"), ("app_a", "0001"))
- graph.add_dependency(("app_a", "0003"), ("app_b", "0002"))
- graph.add_dependency(("app_b", "0002"), ("app_b", "0001"))
- graph.add_dependency(("app_a", "0004"), ("app_c", "0002"))
- graph.add_dependency(("app_c", "0002"), ("app_c", "0001"))
- graph.add_dependency(("app_c", "0001"), ("app_b", "0001"))
- graph.add_dependency(("app_c", "0002"), ("app_a", "0002"))
+ graph.add_dependency("app_a.0004", ("app_a", "0004"), ("app_a", "0003"))
+ graph.add_dependency("app_a.0003", ("app_a", "0003"), ("app_a", "0002"))
+ graph.add_dependency("app_a.0002", ("app_a", "0002"), ("app_a", "0001"))
+ graph.add_dependency("app_a.0003", ("app_a", "0003"), ("app_b", "0002"))
+ graph.add_dependency("app_b.0002", ("app_b", "0002"), ("app_b", "0001"))
+ graph.add_dependency("app_a.0004", ("app_a", "0004"), ("app_c", "0002"))
+ graph.add_dependency("app_c.0002", ("app_c", "0002"), ("app_c", "0001"))
+ graph.add_dependency("app_c.0001", ("app_c", "0001"), ("app_b", "0001"))
+ graph.add_dependency("app_c.0002", ("app_c", "0002"), ("app_a", "0002"))
# Test branch C only
self.assertEqual(
graph.forwards_plan(("app_c", "0002")),
@@ -123,13 +123,51 @@ class GraphTests(TestCase):
graph.add_node(("app_a", "0003"), None)
graph.add_node(("app_b", "0001"), None)
graph.add_node(("app_b", "0002"), None)
- graph.add_dependency(("app_a", "0003"), ("app_a", "0002"))
- graph.add_dependency(("app_a", "0002"), ("app_a", "0001"))
- graph.add_dependency(("app_a", "0001"), ("app_b", "0002"))
- graph.add_dependency(("app_b", "0002"), ("app_b", "0001"))
- graph.add_dependency(("app_b", "0001"), ("app_a", "0003"))
+ graph.add_dependency("app_a.0003", ("app_a", "0003"), ("app_a", "0002"))
+ graph.add_dependency("app_a.0002", ("app_a", "0002"), ("app_a", "0001"))
+ graph.add_dependency("app_a.0001", ("app_a", "0001"), ("app_b", "0002"))
+ graph.add_dependency("app_b.0002", ("app_b", "0002"), ("app_b", "0001"))
+ graph.add_dependency("app_b.0001", ("app_b", "0001"), ("app_a", "0003"))
# Test whole graph
self.assertRaises(
CircularDependencyError,
graph.forwards_plan, ("app_a", "0003"),
)
+
+ def test_plan_invalid_node(self):
+ """
+ Tests for forwards/backwards_plan of nonexistent node.
+ """
+ graph = MigrationGraph()
+ message = "Node ('app_b', '0001') not a valid node"
+
+ with self.assertRaisesMessage(ValueError, message):
+ graph.forwards_plan(("app_b", "0001"))
+
+ with self.assertRaisesMessage(ValueError, message):
+ graph.backwards_plan(("app_b", "0001"))
+
+ def test_missing_parent_nodes(self):
+ """
+ Tests for missing parent nodes.
+ """
+ # Build graph
+ graph = MigrationGraph()
+ graph.add_node(("app_a", "0001"), None)
+ graph.add_node(("app_a", "0002"), None)
+ graph.add_node(("app_a", "0003"), None)
+ graph.add_node(("app_b", "0001"), None)
+ graph.add_dependency("app_a.0003", ("app_a", "0003"), ("app_a", "0002"))
+ graph.add_dependency("app_a.0002", ("app_a", "0002"), ("app_a", "0001"))
+ with self.assertRaisesMessage(KeyError, "Migration app_a.0001 dependencies references nonexistent parent node ('app_b', '0002')"):
+ graph.add_dependency("app_a.0001", ("app_a", "0001"), ("app_b", "0002"))
+
+ def test_missing_child_nodes(self):
+ """
+ Tests for missing child nodes.
+ """
+ # Build graph
+ graph = MigrationGraph()
+ graph.add_node(("app_a", "0001"), None)
+ with self.assertRaisesMessage(KeyError, "Migration app_a.0002 dependencies references nonexistent child node ('app_a', '0002')"):
+ graph.add_dependency("app_a.0002", ("app_a", "0002"), ("app_a", "0001"))
diff --git a/tests/migrations/test_operations.py b/tests/migrations/test_operations.py
index 9987f04..66f7777 100644
--- a/tests/migrations/test_operations.py
+++ b/tests/migrations/test_operations.py
@@ -1278,6 +1278,39 @@ class OperationTests(OperationTestBase):
non_atomic_migration.apply(project_state, editor)
self.assertEqual(project_state.render().get_model("test_runpythonatomic", "Pony").objects.count(), 1)
+ @unittest.skipIf(sqlparse is None and connection.features.requires_sqlparse_for_splitting, "Missing sqlparse")
+ def test_separate_database_and_state(self):
+ """
+ Tests the SeparateDatabaseAndState operation.
+ """
+ project_state = self.set_up_test_model("test_separatedatabaseandstate")
+ # Create the operation
+ database_operation = migrations.RunSQL(
+ "CREATE TABLE i_love_ponies (id int, special_thing int);",
+ "DROP TABLE i_love_ponies;"
+ )
+ state_operation = migrations.CreateModel("SomethingElse", [("id", models.AutoField(primary_key=True))])
+ operation = migrations.SeparateDatabaseAndState(
+ state_operations=[state_operation],
+ database_operations=[database_operation]
+ )
+ self.assertEqual(operation.describe(), "Custom state/database change combination")
+ # Test the state alteration
+ new_state = project_state.clone()
+ operation.state_forwards("test_separatedatabaseandstate", new_state)
+ self.assertEqual(len(new_state.models["test_separatedatabaseandstate", "somethingelse"].fields), 1)
+ # Make sure there's no table
+ self.assertTableNotExists("i_love_ponies")
+ # Test the database alteration
+ with connection.schema_editor() as editor:
+ operation.database_forwards("test_separatedatabaseandstate", editor, project_state, new_state)
+ self.assertTableExists("i_love_ponies")
+ # And test reversal
+ self.assertTrue(operation.reversible)
+ with connection.schema_editor() as editor:
+ operation.database_backwards("test_separatedatabaseandstate", editor, new_state, project_state)
+ self.assertTableNotExists("i_love_ponies")
+
class MigrateNothingRouter(object):
"""
diff --git a/tests/model_inheritance/tests.py b/tests/model_inheritance/tests.py
index 0af96b8..7721017 100644
--- a/tests/model_inheritance/tests.py
+++ b/tests/model_inheritance/tests.py
@@ -255,6 +255,43 @@ class ModelInheritanceTests(TestCase):
1, lambda: ItalianRestaurant.objects.select_related("chef")[0].chef
)
+ def test_select_related_defer(self):
+ """
+ #23370 - Should be able to defer child fields when using
+ select_related() from parent to child.
+ """
+ Restaurant.objects.create(
+ name="Demon Dogs",
+ address="944 W. Fullerton",
+ serves_hot_dogs=True,
+ serves_pizza=False,
+ rating=2,
+ )
+ ItalianRestaurant.objects.create(
+ name="Ristorante Miron",
+ address="1234 W. Ash",
+ serves_hot_dogs=False,
+ serves_pizza=False,
+ serves_gnocchi=True,
+ rating=4,
+ )
+
+ qs = (Restaurant.objects
+ .select_related("italianrestaurant")
+ .defer("italianrestaurant__serves_gnocchi")
+ .order_by("rating"))
+
+ # Test that the field was actually defered
+ with self.assertNumQueries(2):
+ objs = list(qs.all())
+ self.assertTrue(objs[1].italianrestaurant.serves_gnocchi)
+
+ # Test that model fields where assigned correct values
+ self.assertEqual(qs[0].name, 'Demon Dogs')
+ self.assertEqual(qs[0].rating, 2)
+ self.assertEqual(qs[1].italianrestaurant.name, 'Ristorante Miron')
+ self.assertEqual(qs[1].italianrestaurant.rating, 4)
+
def test_mixin_init(self):
m = MixinModel()
self.assertEqual(m.other_attr, 1)
diff --git a/tests/schema/tests.py b/tests/schema/tests.py
index 4222510..c51ef97 100644
--- a/tests/schema/tests.py
+++ b/tests/schema/tests.py
@@ -1,4 +1,3 @@
-from __future__ import absolute_import
import datetime
import unittest
@@ -318,6 +317,9 @@ class SchemaTests(TransactionTestCase):
if connection.vendor == 'mysql':
self.assertEqual(field_type, 'IntegerField')
self.assertEqual(field_info.precision, 1)
+ elif connection.vendor == 'oracle' and connection.version_has_default_introspection_bug:
+ self.assertEqual(field_type, 'IntegerField')
+ self.assertEqual(field_info.precision, 0)
else:
self.assertEqual(field_type, 'BooleanField')
diff --git a/tests/staticfiles_tests/test_liveserver.py b/tests/staticfiles_tests/test_liveserver.py
index b7e309e..dee5091 100644
--- a/tests/staticfiles_tests/test_liveserver.py
+++ b/tests/staticfiles_tests/test_liveserver.py
@@ -1,6 +1,6 @@
"""
A subset of the tests in tests/servers/tests exercicing
-django.contrib.staticfiles.testing.StaticLiveServerCase instead of
+django.contrib.staticfiles.testing.StaticLiveServerTestCase instead of
django.test.LiveServerTestCase.
"""
@@ -11,7 +11,7 @@ from django.test import override_settings
from django.utils.six.moves.urllib.request import urlopen
from django.utils._os import upath
-from django.contrib.staticfiles.testing import StaticLiveServerCase
+from django.contrib.staticfiles.testing import StaticLiveServerTestCase
TEST_ROOT = os.path.dirname(upath(__file__))
@@ -23,7 +23,7 @@ TEST_SETTINGS = {
}
-class LiveServerBase(StaticLiveServerCase):
+class LiveServerBase(StaticLiveServerTestCase):
available_apps = []
@@ -94,8 +94,8 @@ class StaticLiveServerView(LiveServerBase):
def test_collectstatic_emulation(self):
"""
- Test that StaticLiveServerCase use of staticfiles' serve() allows it to
- discover app's static assets without having to collectstatic first.
+ Test that StaticLiveServerTestCase use of staticfiles' serve() allows it
+ to discover app's static assets without having to collectstatic first.
"""
f = self.urlopen('/static/test/file.txt')
self.assertEqual(f.read().rstrip(b'\r\n'), b'In app media directory.')
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-django.git
More information about the Python-modules-commits
mailing list