In Django < 1.6, override_settings restores the settings module that was
active when the override_settings call was executed, not when it was
run. This can make a difference when override_settings is applied to a
class, since it's executed when the module is imported, not when the
test case is run.
In addition, if the settings module for tests is stored alongside the
tests themselves, importing the settings module can trigger an import
of the tests. Since the settings module isn't fully imported yet,
class-level override_settings statements may store a reference to an
incorrect settings module. Eventually this will result in a crash during
test teardown because the settings module restored by override_settings
won't the one that was active during test setup.
While Django should prevent this situation in the future by failing
loudly in such dubious import sequences, that change won't be backported
to 1.5 and 1.4. However, these versions received the "allowed hosts"
patch and they're prone to "AttributeError: 'Settings' object has no
attribute '_original_allowed_hosts'". To mitigate this regression, this
commits stuffs _original_allowed_hosts on a random module instead of the
settings module.
This problem shouldn't occur in Django 1.6, see #20290, but this patch
will be forward-ported for extra safety.
Also tweaked backup variable names for consistency.
Forward port of 0261922 from stable/1.5.x.
Conflicts:
django/test/utils.py
The code examples should now work correctly.
The `get_context_data` method in the examples was changed when
necessary to adopt a singular style (get context with super(...),
add the extra keys to the dict then return it).
Thanks to Remco Wendt for the initial report and to Tim Graham
for the review.
BaseModelFormSet.forms is now a cached property instead of being
populated in the __init__ method. This behaviour also matches an
example in the documentation.
Thanks Thomasz Swiderski for the report and Simon Charette for the
review.
This attribute is only allowed on inputs of type "text", "search", "url",
"tel", "email", or "password".
Thanks to yoyoma for the report and @bmispelon for the review.
There were a couple of places which used Query.join() directly. By
using setup_joins() in these places the code is more DRY, and in
addition there is no need to directly call field.get_joining_columns()
unless the field is the given join_field from get_path_info(). This
makes it easier to make sure a ForeignObject subclass generates joins
correctly in all cases.
