2009년 6월 29일
Django 1.1에 오신 것을 환영합니다!
장고 1.1 버전은 여러 멋진 :ref:`새로운 기능들 <whats-new-1.1>`이 포함되어 있으며, 많은 양의 버그 수정, 그리고 장고 1.0에서 쉽게 업그레이드 할 수 있는 방법이 제공됩니다.
Django는 API 안정성 원칙을 가지고 있습니다. 이는 일반적으로 Django 1.0을 기반으로 개발한 코드가 Django 1.1에서도 수정 없이 그대로 작동해야 함을 의미합니다. 다만, 버그 해결을 위해 꼭 필요한 경우에는 하위 호환성을 깨뜨리는 변경 사항을 도입하기도 하며, Django 1.0과 Django 1.1 사이에도 이와 같은 (작은) 변경 사항들이 극소수 존재합니다.
Django 1.1로 업그레이드하기 전에 아래 변화 사항들이 본인에게 영향을 끼치지 않는지 더블체크해야 합니다. 만약 영향을 끼친다면, 코드를 업그레이드해야 합니다.
Django 1.1은 데이터베이스 제약 조건 이름을 생성하는 방식을 수정하여, 머신 워드 크기와 관계없이 일관된 이름을 생성하도록 변경되었습니다. 이 변경 사항은 일부 사용자에게 하위 호환성 문제를 일으킬 수 있습니다.
32비트 플랫폼을 사용하고 계신다면 해당되지 않습니다. 이 변화로 인해 발생한 결과에 차이를 느끼지 못하실 겁니다.
하지만 64비트 플랫폼을 사용하는 사용자들은 ``reset`` 관리 명령을 사용할 때 일부 문제를 겪을 수 있습니다. 이번 변경 전까지 64비트 플랫폼은 제약 조건 이름에 64비트 기반의 16자 다이제스트를 생성했습니다. 예를 들면 다음과 같습니다. :
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...
이 변경 이후에는 워드 크기에 관계없이 모든 플랫폼에서 제약 조건 이름에 32비트 기반의 8자 다이제스트를 생성하게 됩니다. 예를 들면 다음과 같습니다. :
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
이러한 변경의 결과로, 64비트 머신에서 생성된 어떤 테이블에 대해서도 reset 관리 명령을 사용할 수 없게 됩니다. 이는 새로 생성되는 이름이 기존에 생성되었던 이름과 일치하지 않기 때문이며, 결과적으로 reset 명령에 의해 구성된 SQL 문은 유효하지 않게 됩니다.
64비트 제약 조건이 적용된 상태로 생성된 애플리케이션을 초기화해야 한다면, reset 명령을 실행하기 전에 기존의 오래된 제약 조건을 수동으로 삭제해야 합니다.
Django 1.1은 트랜잭션 내부에서 테스트를 실행하여 더 나은 테스트 성능을 제공합니다 (자세한 내용은 test performance improvements 를 참조하세요).
이 변경 사항은 기존 테스트가 트랜잭션 동작을 테스트해야 하거나, 테스트 환경에 대한 잘못된 가정에 의존하거나, 특정 테스트 케이스 순서를 필요로 하는 경우 약간 하위 호환되지 않습니다.
이러한 경우에는 :class:~django.test.TransactionTestCase를 대신 사용할 수 있습니다. 이는 새로운 롤백 방식으로 인해 드러난 테스트 케이스 오류를 우회하기 위한 임시 해결책일 뿐이며, 장기적으로는 해당 테스트를 올바른 형태로 다시 작성해야 합니다.
SetRemoteAddrFromForwardedFor middleware¶For convenience, Django 1.0 included an optional middleware class –
django.middleware.http.SetRemoteAddrFromForwardedFor – which updated the
value of REMOTE_ADDR based on the HTTP X-Forwarded-For header commonly
set by some proxy configurations.
It has been demonstrated that this mechanism cannot be made reliable enough for
general-purpose use, and that (despite documentation to the contrary) its
inclusion in Django may lead application developers to assume that the value of
REMOTE_ADDR is “safe” or in some way reliable as a source of
authentication.
While not directly a security issue, we’ve decided to remove this middleware
with the Django 1.1 release. It has been replaced with a class that does
nothing other than raise a DeprecationWarning.
만약 당신이 이 미들웨어를 이용해왔다면, 가장 쉬운 업그레이드 경로는:
Verify that it works correctly with your upstream proxy, modifying it to support your particular proxy (if necessary).
Introduce your modified version of SetRemoteAddrFromForwardedFor as a
piece of middleware in your own project.
In Django 1.0, files uploaded and stored in a model’s FileField were
saved to disk before the model was saved to the database. This meant that the
actual file name assigned to the file was available before saving. For example,
it was available in a model’s pre-save signal handler.
In Django 1.1 the file is saved as part of saving the model in the database, so the actual file name used on disk cannot be relied on until after the model has been saved.
In Django 1.1, BaseModelFormSet now calls
ModelForm.save().
This is backwards-incompatible if you were modifying self.initial in a
model formset’s __init__, or if you relied on the internal
_total_form_count or _initial_form_count attributes of BaseFormSet.
Those attributes are now public methods.
join filter’s escaping behavior¶The join filter no longer escapes the literal value that is
passed in for the connector.
This is backwards incompatible for the special situation of the literal string
containing one of the five special HTML characters. Thus, if you were writing
{{ foo|join:"&" }}, you now have to write {{ foo|join:"&" }}.
The previous behavior was a bug and contrary to what was documented and expected.
redirect_to() generic view¶Django 1.1 adds a permanent argument to the
django.views.generic.simple.redirect_to() view. This is technically
backwards-incompatible if you were using the redirect_to view with a
format-string key called ‘permanent’, which is highly unlikely.
One feature has been marked as deprecated in Django 1.1:
You should no longer use AdminSite.root() to register that admin
views. That is, if your URLconf contains the line:
(r"^admin/(.*)", admin.site.root),
You should change it to read:
(r"^admin/", include(admin.site.urls)),
You should begin to remove use of this feature from your code immediately.
AdminSite.root will raise a PendingDeprecationWarning if used in
Django 1.1. This warning is hidden by default. In Django 1.2, this warning will
be upgraded to a DeprecationWarning, which will be displayed loudly. Django
1.3 will remove AdminSite.root() entirely.
For more details on our deprecation policies and strategy, see Django의 릴리스 과정.
Quite a bit: since Django 1.0, we’ve made 1,290 code commits, fixed 1,206 bugs, and added roughly 10,000 lines of documentation.
Django 1.1 의 주요한 새로운 기능들은:
Two major enhancements have been added to Django’s object-relational mapper (ORM): aggregate support, and query expressions.
It’s now possible to run SQL aggregate queries (i.e. COUNT(), MAX(),
MIN(), etc.) from within Django’s ORM. You can choose to either return the
results of the aggregate directly, or else annotate the objects in a
QuerySet with the results of the aggregate
query.
This feature is available as new
aggregate() and
annotate() methods, and is covered in
detail in the ORM aggregation documentation.
Queries can now refer to another field on the query and can traverse
relationships to refer to fields on related models. This is implemented in the
new F object; for full details, including examples,
consult the F expressions documentation.
A number of features have been added to Django’s model layer:
You can now control whether or not Django manages the life-cycle of the
database tables for a model using the managed model option.
This defaults to True, meaning that Django will create the appropriate
database tables in syncdb and remove them as part of the reset command.
That is, Django manages the database table’s lifecycle.
If you set this to False, however, no database table creating or deletion
will be automatically performed for this model. This is useful if the model
represents an existing table or a database view that has been created by some
other means.
더 많은 사항들은 :attr:`~Options.managed`option 에 관한 문서를 확인하세요.
You can now create proxy models: subclasses of existing models that only add Python-level (rather than database-level) behavior and aren’t represented by a new table. That is, the new model is a proxy for some underlying model, which stores all the real data.
All the details can be found in the proxy models documentation. This feature is similar on the surface to unmanaged models, so the documentation has an explanation of how proxy models differ from unmanaged models.
In some complex situations, your models might contain fields which could contain a lot of data (for example, large text fields), or require expensive processing to convert them to Python objects. If you know you don’t need those particular fields, you can now tell Django not to retrieve them from the database.
You’ll do this with the new queryset methods
defer() and
only().
A few notable improvements have been made to the testing framework.
Tests written using Django’s testing framework now run dramatically faster (as much as 10 times faster in many cases).
This was accomplished through the introduction of transaction-based tests: when
using django.test.TestCase, your tests will now be run in a
transaction which is rolled back when finished, instead of by flushing and
re-populating the database. This results in an immense speedup for most types
of unit tests. See the documentation for TestCase and
TransactionTestCase for a full description, and some important notes
on database support.
A couple of small – but highly useful – improvements have been made to the test client:
The test Client now can automatically follow redirects with the
follow argument to Client.get() and Client.post(). This
makes testing views that issue redirects simpler.
It’s now easier to get at the template context in the response returned
the test client: you’ll simply access the context as
request.context[key]. The old way, which treats request.context as
a list of contexts, one for each rendered template in the inheritance
chain, is still available if you need it.
Django 1.1 adds a couple of nifty new features to Django’s admin interface:
You can now make fields editable on the admin list views via the new list_editable admin option. These fields will show up as form widgets on the list pages, and can be edited and saved in bulk.
You can now define admin actions that can perform some action to a group of models in bulk. Users will be able to select objects on the change list page and then apply these bulk actions to all selected objects.
Django ships with one pre-defined admin action to delete a group of objects in one fell swoop.
Django now has much better support for conditional view processing using the standard ETag and
Last-Modified HTTP headers. This means you can now easily short-circuit
view processing by testing less-expensive conditions. For many views this can
lead to a serious improvement in speed and reduction in bandwidth.
Django 1.1 improves named URL patterns with the introduction of URL “namespaces.”
In short, this feature allows the same group of URLs, from the same application, to be included in a Django URLConf multiple times, with varying (and potentially nested) named prefixes which will be used when performing reverse resolution. In other words, reusable applications like Django’s admin interface may be registered multiple times without URL conflicts.
For full details, see the documentation on defining URL namespaces.
In Django 1.1, GeoDjango (i.e.
django.contrib.gis) has several new features:
Support for SpatiaLite – a spatial database for SQLite – as a spatial backend.
Geographic aggregates (Collect, Extent, MakeLine, Union)
and F expressions.
New GeoQuerySet methods: collect, geojson, and
snap_to_grid.
A new list interface methods for GEOSGeometry objects.
For more details, see the GeoDjango documentation.
Other new features and changes introduced since Django 1.0 include:
The CSRF protection middleware has been split into
two classes – CsrfViewMiddleware checks incoming requests, and
CsrfResponseMiddleware processes outgoing responses. The combined
CsrfMiddleware class (which does both) remains for
backwards-compatibility, but using the split classes is now recommended in
order to allow fine-grained control of when and where the CSRF processing
takes place.
reverse() and code which uses it (e.g., the {% url %} template tag)
now works with URLs in Django’s administrative site, provided that the admin
URLs are set up via include(admin.site.urls) (sending admin requests to
the admin.site.root view still works, but URLs in the admin will not be
“reversible” when configured this way).
The include() function in Django URLconf modules can now accept sequences
of URL patterns (generated by patterns()) in addition to module names.
Instances of Django forms (see the forms overview) now have two additional methods, hidden_fields()
and visible_fields(), which return the list of hidden – i.e.,
<input type="hidden"> – and visible fields on the form, respectively.
The redirect_to generic view
now accepts an additional keyword argument permanent. If permanent is
True, the view will emit an HTTP permanent redirect (status code 301). If
False, the view will emit an HTTP temporary redirect (status code 302).
A new database lookup type – week_day – has been added for
DateField and DateTimeField. This type of lookup accepts a number
between 1 (Sunday) and 7 (Saturday), and returns objects where the field
value matches that day of the week. See the full list of lookup types for details.
The {% for %} tag in Django’s template language now accepts an optional
{% empty %} clause, to be displayed when {% for %} is asked to loop
over an empty sequence. See the list of built-in template tags for examples of this.
The dumpdata management command now accepts individual
model names as arguments, allowing you to export the data just from
particular models.
There’s a new safeseq template filter which works just like
safe for lists, marking each item in the list as safe.
Cache backends now support incr() and
decr() commands to increment and decrement the value of a cache key.
On cache backends that support atomic increment/decrement – most
notably, the memcached backend – these operations will be atomic, and
quite fast.
Django now can easily delegate authentication to the web server via a new authentication backend that supports
the standard REMOTE_USER environment variable used for this purpose.
There’s a new django.shortcuts.redirect() function that makes it
easier to issue redirects given an object, a view name, or a URL.
The postgresql_psycopg2 backend now supports native PostgreSQL
autocommit. This is an advanced, PostgreSQL-specific
feature, that can make certain read-heavy applications a good deal
faster.
We’ll take a short break, and then work on Django 1.2 will begin – no rest for
the weary! If you’d like to help, discussion of Django development, including
progress toward the 1.2 release, takes place daily on the django-developers
mailing list and in the #django-dev IRC channel on irc.libera.chat.
Feel free to join the discussions!
Django’s online documentation also includes pointers on how to contribute to Django:
Contributions on any level – developing code, writing documentation or simply triaging tickets and helping to test proposed bugfixes – are always welcome and appreciated.
And that’s the way it is.
8월 05, 2026