# Dokumentasi Django 5.2.8

# Catatan terbitan Django 1.2

Mei 17, 2010.

Selamat datang di Django 1.2!

Hanpir setahun dalam membuat, Django 1.2 membungkus sebuah daftar mengagumkan dari new features dan banyak perbaikan kesalahan. Catatan terbitan ini mencangkupi fitur-fitur baru, sama pentingnya perubahan anda akan ingin sadari ketika meningkatkan dari Django 1.1 atau versi terlama.

## Ikhtisar

Django 1.2 memperkenalkan beberapa besar, fitur baru penting, termasuk:

- Support for multiple database connections in a single Django instance.

- Model validation diilhami oleh pemeriksaan formulir Django.

- Vastly improved protection against Cross-Site Request Forgery (CSRF).

- A new user "messages" framework with support for cookie- and session-based message for both anonymous and authenticated users.

- Hooks for object-level permissions, permissions for anonymous users, and more flexible username requirements.

- Penyesuaian dari pengiriman surel melalui email backends.

- Baru "smart" if template tag yang mendukung penghubung perbandingan.

These are just the highlights; full details and a complete list of features may be found below.

Lihat juga

Django Advent melingkupi terbitan dari Django 1.2 dengan rangkaian dari artikel dan tutorial yang melingkupi beberapa dari fitur baru secara dalam.

Dimana memungkinkan fitur-fitur ini telah diperkenalkan di sikap kesesuaian-kebelakang per kebijakan our API stability policy.

Bagaimanapun, bantuan dari fitur telah berubah dalam cara-cara yang, untuk beberapa pengguna, akan bertentangan kebelakang. Perubahan besar adalah:

- Dukungan untuk Python 2.3 telah dibuang. Lihat catatan penuh dibawah.

- Kerangka kerja perlindungan CSRF baru tidak kesesuaian-kebelakang dengan sistem lama. Pengguna dari sistem lama akan tidak terpengaruh sampai sistem lama dipindahkan di Django 1.4.

  Bagaimanapun, meningkatkan kekerangka kerja perlindungan CSRF baru membutuhkan beberapa perubahan bertentangan kebelakang, rincian dalam CSRF Protection, dibawah.

- Penulis dari subkelas `Field` penyesuaian harus menyadari bahwa sejumlah metode telah berubah di purwa rupa, rincian dibawah get_db_prep_*() methods on Field, dibawah.

- Internal dari etiket cetakan telah berubah sedikit; penulis dari etiket cetakan penyesuaian yang butuh untuk menyimpan keadaan (sebagai contoh penyesuaian pengendalian aliran etiket) harus memastikan bahwa kode mereka mengikuti aturan baru untuk stateful template tags

- The `user_passes_test()`, `login_required()`, and `permission_required()`, decorators from `django.contrib.auth` only apply to functions and no longer work on methods. There's a simple one-line fix detailed below.

Kembali, ini hanya fitur besar yang akan mempengaruhi kebanyakan pengguna. Pengguna meningkatkan dari versi sebelumnya dari Django didorong untuk konsultasi daftar lengkap dari backwards-incompatible changes dan daftar dari deprecated features.

## Kesesuaian Python

Selama bukan fitur baru, adalah penting untuk dicatat bahwa Django 1.2 memperkenalkan perpindahan pertama dalam kesesuaian Python kami sejak permulaan tampil umum. Terbitan Django sebelumnya telah diuji dan didukung pada versi Python 2.x dari 2.3 keatas; Django 1.2, bagaimanapun, menjatuhkan dukungan resmi untuk Python 2.3. Dengan demikian, versi Python minimal dibutuhkan untuk Django sekarang adalah 2.4, dan Django diuji dan didukung pada Python 2.4, 2.5 dan 2.6, dan akan didukung pada yang belum pernah diterbitkan Python 2.7.

Perubahan ini seharusnya berakibat hanya angka kecil dari pengguna Django, seperti kebanyakan penjaja sistem operasi hari ini yang membekali Python 2.4 atau memperbaharui versi awal mereka. Jika anda masih menggunakan Python 2.3, bagaimanapun, anda akan butuh melekat ke Django 1.1 sampai anda dapat meningkatkan; per kebijakan dukungan kami, Django 1.1 akan lanjut menerima dukungan keamanan sampai terbitan dari Django 1.3.

Sebuah peta jalan untuk dukungan keseluruhan Python 2.x Django, dan akhirnya berpindah ke Python 3.x, saat ini sedang dikembangkan, dan akan diumumkan sebelum terbitan dari Django 1.3.

## Apa yang baru di Django 1.2

### Mendukung untuk banyak basisdata

Django 1.2 menambahkan kemampuan untuk menggunakan lebih dari satu basisdata di proyek Django anda. Permintaan dapat diterbitkan pada basisdata khusus dengan menggunakan metode `using()` pada obyek `QuerySet`. Obyek tersendiri dapat disimpan pada basisdata khusus dengan menyediakan argumen `using` ketika anda memanggil `save()`.

### Validasi model

Instance model sekarang telah mendukung untuk validating their own data, dan kedua model bidang formulir sekarang menerima daftar dapat dikonfigurasi dari validators menentukan dapat digunakan kembali, mengemas perilaku pengesahan. Catat, bagaimanapun, pengesahan itu harus masih dilakukan secara eksplisit. Cukup meminta sebuah metode `save()` instance model tidak akan melakukan pengesahan apapun dari data instance.

### Perbaikan perlindungan CSRF

Django sekarang mempunyai banyak peningkatan perlindungan terhadap Serangan Cross-Site Request Forgery (CSRF). Jenis serangan ini muncuk ketika situs jahat mengandung sebuah tautan, sebuah tombol formulir atau beberapa JavaScript yang berusaha melakukan beberapa tindakan pada situs jaringan anda, menggunakan mandat dari pengguna masuk yang mengunjungi situs jahat di peramban mereka. Jenis terkait dari serangan, "login CSRF," dimana sebuah situs penyerang mengelabui perambah pengguna kedalam pemasukan kedalam sebuah situs dengan mandat orang lain, juga dicakupi.

### Kerangka pesan

Django sekarang menyertakan kerangka pesan yang kuat dan dapat dikonfigurasi dengan dukungan siap-pakai untuk berdasar pesan kue- dan sesi, untuk kedua anonim dan klien terperiksa keasliannya. Kerangka pesan menggantikan API pesan pengguna usang dan mengizinkan anda untuk sementara menyimpan pesan dalam satu permintaan dan menarik mereka untuk ditampilkan dalam permintaan berikut (biasanya selanjutnya).

### Tingkat-obyek perizinan

Sebuah yayasan untuk menentukan perizinan pada tingkatan per obyek telah ditambahkan. Meskipun tidak ada penerapan dari ini dalam inti, backend pembuktian keaslian penyesuaian dapat menyediakan penerapan ini dan akan dipakai oleh `django.contrib.auth.models.User`. Lihat authentication docs untuk informasi lebih.

### Perizinan untuk pengguna anonim

If you provide a custom auth backend with `supports_anonymous_user` set to `True`, AnonymousUser will check the backend for permissions, just like User already did. This is useful for centralizing permission handling - apps can always delegate the question of whether something is allowed or not to the authorization/authentication backend. See the authentication docs for more details.

### Persyaratan santai untuk nama pengguna

Bidang `User` siap-pakai `username` model sekarang mengizinkan jangkauan luas dari karakter, termasuk karakter `@`, `+`, `.` and `-`.

### Backend surel

Anda dapat sekarang mengkonfigurasi cara Django mengirim surel. Daripada menggunakan SMTP untuk mengirim semua surel, anda dapat sekarang memilih backend surel dikonfigurasi untuk mengirim surel. Jika penyedia rumah anda menggunakan bak pasir atau beberapa lainnya teknik bukan-SMTP untuk mengirim surat, anda dapat sekarang membangun sebuah surel yang akan mengizinkan standar Django mail sending methods untuk menggunakan fasilitas tersebut.

Ini juga membuatnya mudah untuk mencari kesalahan pengiriman surat. Django mengirim dengan penerapan backend yang mengizinkan anda mengirim surat ke file, ke console, atau ke memory. Anda dapat bahkan mengkonfigurasi semua surel untuk menjadi thrown away.

### Etiket "Smart" `if`

Etiket `if` telah ditingkatkan ke lebih kuat. Pertama, kami telah menambahkan dukungan untuk perbandingan penghubung. Tidak lagi akan anda ketik:

    {% ifnotequal a b %}
     ...
    {% endifnotequal %}

Anda dapat sekarang melakukan ini:

    {% if a != b %}
     ...
    {% endif %}

Tidak ada alasan untuk menggunakan``{% ifequal %}`` atau `{% ifnotequal %}` lagi, meskipun anda adalah jenis yang rindu.

Penghubung yang didukung adalah `==`, `!=`, `<`, `>`, `<=`, `>=`, `in` dan `not in`, semua yang bekerja seperti penghubung Python, sebagai tambahan pada `and`, `or` dan `not`, yang sudah didukung.

Juga, penyaring sekarang dapat digunakan dalam pernyataan `if`. Sebagai contoh:

    <div
      {% if user.email|lower == message.recipient|lower %}
        class="highlight"
      {% endif %}
    >{{ message }}</div>

### Cetakan penyembunyian

Di versi Django sebelumnya, setiap kali anda membangun sebuah cetakan, itu akan dimuat kembali dari cakram. Di Django 1.2, anda dapat menggunakan cached template loader untuk memuat cetakan sekali, kemudian menembolok hasil untuk setiap pembangun berikutnya. Ini akan membawa ke perbaikan penampilan yang signifikan jika cetakan anda dipecah kedalam banyak sub cetakan kecil (menggunakan etiket `{% extends %}` atau `{% include %}`).

Sebagai efek samping, itu sekarang lebih mudah mendukung bahasa cetakan bukan-Django.

### Pemuat cetakan berdasarkan kelas

Sebagai bagian dari perubahan dibuat untuk memperkenalkan Template caching dan mengikuti tren umum di Django, cetakan pemuat API telah dirubah untuk menggunakan mekanisme pemuat cetakan yang dibungkus dalam kelas-kelas Python sebagai lawan dari fungsi, hanya metode tersedia sampai Django 1.1.

Semua pemuat cetakan shipped with Django telah ditaruh pada API baru tetapi mereka masih menerapkan API berdasarkan-fungsi dan perlengkapan utama cetakan amsih menerima pemuat berdasarkan-fungsi (siap pakai atau pihak ketiga) jadi tidak ada kebutuhan segera untuk merubah pengaturan `TEMPLATE_LOADERS` anda dalam proyek yang ada, hal-hal akan tetap bekerja jika anda membiarkannya tidak tersentuh dan menyertakan terbitan Django 1.3.

If you have developed your own custom template loaders we suggest to consider porting them to a class-based implementation because the code for backwards compatibility with function-based loaders starts its deprecation process in Django 1.2 and will be removed in Django 1.4. There is a description of the API these loader classes must implement in the template API reference and you can also examine the source code of the loaders shipped with Django.

### Kunci alami di perlengkapan

Alat bantu sekarang dapat mengacu pada obyek terpencil menggunakan Kunci alami. Skema pencarian ini adalah sebuah pilihan lain untuk primary-key biasa berdasarkan obyek acuan di alat bantu, meningkatkan kesiapan dan mengatasi masalah mengacu pada obyek yang nilai primary key mungkin tidak dapat diprediksi atau dikenal.

### Kegagalan cepat untuk percobaan

Kedua sub perintah `test` dari `django-admin.py` dan tulisan `runtests.py` digunakan untuk menjalankan deretan percobaan sendiri Django sekarang mendukung -- pilihan `--failfast`. Ketika menentukan, pilihan ini menyebabkan penjalan percobaan keluar setelah menghadapi kegagalan daripada melanjutkan dengan percobaan berjalan. Sebagai tambahan, penanganan dari `Ctrl-C` selama percobaan berjalan telah diperbaiki untuk memicu keluar yang anggun dari percobaan berjalan yang melaporkan rincian dari percobaan yang telah dijalankan sebelum gangguan.

### `BigIntegerField`

Model dapat sekarang menggunakan jenis `BigIntegerField` 64-bit.

### Perbaikan lokalisasi

internationalization framework Django telah diperluas dengan bentukan sadar-lokal dan pengolahan formulir. Itu berarti, jika diadakan, tanggal dan angka pada cetakan akan ditampilkan menggunakan bentuk ditentukan untuk lokal saat ini. Django akan juga menggunakan bentuk lokalisasi ketika mengurai data dalam formulir. Lihat Bentuk lokalisasi untuk rincian lebih.

### `readonly_fields` di `ModelAdmin`

`django.contrib.admin.ModelAdmin.readonly_fields` telah ditambahkan untuk mengadakan bidang tidak dapat disunting dalam halaman tambah/rubah untuk model dan berderet. Bidang dan nilai dihitung dapat ditampilkan bersama bidang dapat disunting.

### Penyorotan sintaksis disesuaikan

You can now use a `DJANGO_COLORS` environment variable to modify or disable the colors used by `django-admin.py` to provide syntax highlighting.

### Umpan perkongsian sebagai tampilan

Syndication feeds sekarang dapat digunakan secara langsung sebagai tampilan dalam URLconf anda. Ini berarti bahwa anda dapat merawat kendali sepenuhnya terhadap struktur URL dari umpan anda. Seperti tampilan lainnya, tampilan umpan melewatkan obyek `request`, jadi anda dapat melakukan apapun anda akan lalukan secara biasa dengan tampilan, seperti kendali akses berdasarkan pengguna, atau membuat sebuah umpan URL dinamai.

### GeoDjango

The most significant new feature for GeoDjango in 1.2 is support for multiple spatial databases. As a result, the following spatial database backends are now included:

- `django.contrib.gis.db.backends.postgis`

- `django.contrib.gis.db.backends.mysql`

- `django.contrib.gis.db.backends.oracle`

- `django.contrib.gis.db.backends.spatialite`

GeoDjango sekarang mendukung kemampuan kaya ditambahkan di terbitan PostGIS 1.5. Fitur baru termasuk dukungan untuk geography type dan mengadakan distance queries dengan geometri tidak-bertitik pada sistem kordinat geografis.

Dukungan untuk bidang geometri 3D telah ditambahkan, dan mungkin diadakan dengan mengatur kata kunci `dim` menjadi 3 di `GeometryField` anda. Kumpulan `Extent3D` dan metode `extent3d()` `GeoQuerySet` telah ditambahkan sebagai bagian dari fitur ini.

Metode-metode `GeoQuerySet` `force_rhr()`, `reverse_geom()`, dan `geohash()` adalah baru.

Antarmuka GEOS telah diperbaharui untuk menggunakan fungsi pustaka C thread-safe ketika tersedia pada serambi.

Antarmuka GDAL sekarang mengizinkan pengguna untuk menyetel `spatial_filter` pada fitur-fitur dikembalikan ketika berputar terhadap `Layer`.

Finally, GeoDjango's documentation is now included with Django's and is no longer hosted separately at `geodjango.org`.

### Penanganan dibantu-JavaScript dari obyek terhubung berderet di admin

Jika pengguna mempunyai JavaScript diadakan di peramban mereka, antarmuka untuk obyek berderet di admin sekarang mengizinkan obyek berderet untuk secara dinamis ditambahkan dan dipindahkan. Pengguna tanpa perambah diadakan-JavaScript akan melihat tidak ada perubahan di perilaku dari obyek berderet.

### Bentuk etiket cetakan `Now` baru menentukan karakter: `c` dan `u`

Argumen pada `now` telah mendapatkan dua bentuk karakter baru: `c` untuk menentukan bahwa nilai tanggal waktu harus dibentukkan dalam bentuk ISO 8601, dan `u` yang mengizinkan keluaran dari bagian mikrodetik dari nilai tanggal waktu atau waktu.

Ini juga tersedia di bagian lain seperti tfilter:date dan `time` template filters, pustaka etiket cetakan `humanize` dan kerangka kerja format localization baru.

## Perubahan bertentangan kebelakang di 1.2

Dimanapun memungkinkan fitur baru diatas telah diperkenalkan dalam sikap kesesuaian kebelakang per kebijakan our API stability policy. Ini berarti bahwa sebenarnya semua kode yang ada yang bekerja dengan Django 1.1 akan berlanjut bekerja dengan Django 1.2; kode itu akan, bagaimanapun, mulai menerbitkan peringatan (lihat dibaah untuk rincian).

Bagaimanapun, segenggam dari fitur-fitur telah berubah di cara-cara itu, untuk beberapa pengguna, akan segera ketidaksesuaian kebelakang. Perubahan-perubahan tersebut dirinci dibawah.

### Proteksi CSRF

Kami telah membuat perubahan besar pada cara perlindungan CSRF bekerja, rincian di the CSRF documentation. Ini adalah perubahan utama anda harus sadari:

- `CsrfResponseMiddleware` dan `CsrfMiddleware` telah diusangkan dan akan dipindahkan sepenuhnya di Django 1.4, dalam mendukung dari etiket cetakan yang harus dimasukkan kedalam formulir.

- Semua aplikasi bantuan menggunakan penghias `csrf_protect` untuk melindungi tampilan. Ini mewajibkan penggunaan dari etiket cetakan `csrf_token` di cetakan. Jika anda telah menggunakan cetakan penyesuaian untuk tampilan bantuan, anda HARUS MEMBACA PERINTAH PENINGKATAN untuk memperbaiki cetakan tersebut.

  Dokumentasi dipindahkan

  Catatan peningkatan telah dipindahkan di dokumen Django saat ini. Silahkan mengacu ke dokumen untuk Django 1.3 atau lebih lama untuk menemukan perintah-perintah ini.

- `CsrfViewMiddleware` disertakan dalam `MIDDLEWARE_CLASSES` secara awalan. Ini mengubah perlindungan CSRF secara awalan, sehingga tampilan yang menerima permintaan POST butuh ditulis untuk bekerja dengan middleware. Petunjuk-petunjuk pada bagaimana melakukan ini ditemukan dalam dokumen CSRF.

- Semua CSRF telah dipindahkan dari bantuan ke inti (dengan impor kesesuaian kebelakang di tempat lama, yang diusangkan dan akan berhenti didukung di Django 1.4).

### Metode `get_db_prep_*()` pada `Field`

Sebelum DJango 1.2, `Field` penyesuaian mempunyai pilihan dari menentukan beberapa fungsi untuk mendukung perubahan dari nilai-nilai Python kedalam nilai-nilai basisdata-sesuai. Bidang penyesuaian mungkin terlihat seperti:

    class CustomModelField(models.Field):
        ...

        def db_type(self): ...

        def get_db_prep_save(self, value): ...

        def get_db_prep_value(self, value): ...

        def get_db_prep_lookup(self, lookup_type, value): ...

Di 1.2, ketiga metode ini telah menjalani perubahan di purwa rupa, dan dua tambahan metode telah diperkenalkan:

    class CustomModelField(models.Field):
        ...

        def db_type(self, connection): ...

        def get_prep_value(self, value): ...

        def get_prep_lookup(self, lookup_type, value): ...

        def get_db_prep_save(self, value, connection): ...

        def get_db_prep_value(self, value, connection, prepared=False): ...

        def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False): ...

Perubahan ini dibutuhkan untuk mendukuna banyak basisdata -- `db_type` dan `get_db_prep_*` dapat tidak lagi membuat perandaian apapun mengenai basisdata untuk dimana itu dipersiapkan. Argumen `connection` sekarang menyediakan metode persiapan dengan hubungan khusus untuk nilai mana sedang dipesiapkan.

Dua metode baru yang ada untuk membedakan persyaratan persiapan-data umum dari persyaratan yang merupakan basisdata-khusus. Argumen `prepared` digunakan untuk menunjukkan pada metode persiapan-basisdata apakah persiapan nilai umum telah dilakukan. Jika nilai tidak dipersiapkan (yaitu `prepared=False`) disediakan pada panggilan `get_db_prep_*()`, mereka harus meminta panggilan `get_prep_*()` yang sesuai untuk melakukan persiapan data umum.

Kami telah menyediakan fungsi perubahan yang akan secara terbuka merubah fungsi berpegang pada purwa rupa lama kedalam fungsi sesuai dengan purwa rupa baru. Bagimanapun, fungsi perubahan ini akan dipindahkan di Django 1.4, jadi anda harus meningkatkan pengertian `Field` anda untuk menggunakan purwa rupa baru secepat mungkin.

Jika metode `get_db_prep_*()` anda membuat tidak ada penggunaan hubungan basisdata, anda harus dapat meningkatkan dengan menamai kembali `get_db_prep_value()` menjadi `get_prep_value()` dan `get_db_prep_lookup()` menjadi `get_prep_lookup()`. Jika anda membutuhkan perubahan khusus basisdata, kemudian anda akan butuh menyediakan sebuah penerapan `get_db_prep_*` yang menggunakan argumen `connection` untuk menyelesaikan nilai-nilai basisdata-khsuus.

### Etiket cetakan mempertahan keadaan

Etiket cetakan yang menyimpan keadaan membangun pada subkelas `Node` mereka selalu rentan pada thread-safety dan masalah-masalah lain; seperti Django 1.2, bagaimanapun, mereka juga menyebabkan masalah ketika digunakan dengan cached template loader baru.

Semua etiket cetakan Django siap-pakai adalah aman untuk digunakan dengan pemuat disimpan sementara, tetapi jika anda sedang menggunakan etiket cetakan penyesuaian yang datang dari paket pihak ketiga, atau dari kode anda sendiri, anda harus memastikan bahwa penerapan `Node` untuk setiap etiket adalah thread-safe. Untuk informasi lebih, lihat template tag thread safety considerations.

You may also need to update your templates if you were relying on the implementation of Django's template tags not being thread safe. The `cycle` tag is the most likely to be affected in this way, especially when used in conjunction with the `include` tag. Consider the following template fragment:

    {% for object in object_list %}
        {% include "subtemplate.html" %}
    {% endfor %}

dengan `subtemplate.html` yang membaca:

    {% cycle 'even' 'odd' %}

Using the non-thread-safe, pre-Django 1.2 renderer, this would output:

    even odd even odd ...

Using the thread-safe Django 1.2 renderer, you will instead get:

    even even even even ...

Ini karena setiap membangun dari etiket `include` adalah sebuah membangun berdiri sendiri. Ketika etiket `cycle` bukan thread safe, keadaan dari etiket `cycle` akan bocor diantara banyak membangun dari `include` yang sama. Sekarang etiket `cycle` adalah thread safe, kebocoran ini tidak lagi muncul.

### `user_passes_test`, `login_required` dan `permission_required`

`django.contrib.auth.decorators` menyediakan penghias `login_required`, `permission_required` dan `user_passes_test`. Sebelumnya itu dimungkinkan menggunakan kedua penghias ini pada fungsi (dimana argumen partama adalah 'request') dan pada cara (dimana argumen pertama adalah 'self', dan argumen kedua adalah 'request'). Sayangnya, kelemahan-kelemahan ditemukan di kode yang mendukung ini: itu hanya bekerja di keadaan terbatas, dan menghasilkan kesalahan yang sangat sulit untuk dicari kesalahan ketika itu tidak bekerja.

Untuk alasan ini, perilaku 'auto adapt' telah dipindahkan, dan jika anda sedang menggunakan penghias pada metode, anda akan butuh untuk secara manual memberlakukan `django.utils.decorators.method_decorator()` untuk merubah penghias menjadi satu yang bekerja dengan cara ini. Sebagai contoh, anda akan merubah kode dari ini:

    class MyClass(object):
        @login_required
        def my_view(self, request):
            pass

untuk ini:

    from django.utils.decorators import method_decorator

    class MyClass(object):
        @method_decorator(login_required)
        def my_view(self, request):
            pass

atau:

    from django.utils.decorators import method_decorator

    login_required_m = method_decorator(login_required)

    class MyClass(object):
        @login_required_m
        def my_view(self, request):
            pass

Untuk siapa dari anda yang telah mengikuti tempat pengembangan, perubahan ini juga berlaku ke penghias lain diperkenalkan sejak 1.1, termasuk `csrf_protect`, `cache_control` dan apapun dibuat menggunakan `decorator_from_middleware`.

### Etiket `if` berubah

Dikarenakan fitur baru di etiket cetakan `if`, itu tidak lagi menerima 'and', 'or' dan 'not' sebagai nama-nama variabel yang sah. Sebelumnya, deretan karakter ini dapat digunakan sebagai nama-nama variabel. Sekarang, keadaan kata kunci selau dipaksakan, dan kode cetakan seperti `{% if not %}` atau `{% if and %}` akan melemparkan sebuah `TemplateSyntaxError`. Juga, `in` adalah sebuah kata kunci baru dan jadi nama variabel tidak sah di etiket ini.

### `LazyObject`

`LazyObject` adalah sebuah kelas kegunaan tidak-terdokumentasikan-tetapi-sering-digunakan digunakan untuk pembungkusan malas obyek lain dari jenis tidak dikenal.

Di Django 1.1 dan paling awal, itu menangani interspeksi di jalan bukan-standar, tergantung pada obyek dibungkus menerapkan metode umum dinamai `get_all_members()`. Karena ini dapat dengan mudah membawa ke tabrakan nama, itu telah dirubah untuk menggunakan metode standar interospeksi Python, melibatkan `__members__` dan `__dir__()`.

Jika anda menggunakan `LazyObject` di kode anda sendiri dan menerapkan metode `get_all_members()` untuk obyek dibungkus, anda akan butuh membuat sepasang perubahan:

Pertama, jika kelas anda tidak mempunyai persyaratan khusus untuk interospeksi (yaitu, anda belum menerapkan `__getattr__()` atau metode lainnya yang mengizinkan untuk atribut tidak dapat ditemukan oleh mekanisme biasa), anda dapat cukup memindahkan metode `get_all_members()`. Penerapan awal pada `LazyObject` akan melakukan hal benar.

Jika anda mempunyai persyaratan lebih rumit untuk interospeksi, pertama namai kembali metode `get_all_members()` pada `__dir__()`. Ini adalah metode interospeksi standar untuk Python 2.6 dan diatas. Jika anda membutuhkan dukungan untuk versi awal Python dari 2.6, tambah kode berikut pada kelas:

    __members__ = property(lambda self: self.__dir__())

### `__dict__` pada instance model

Secara riwayat, atribut `__dict__` dari sebuah instance model mempunyai hanya atribut mengandung hubungan ke bidang pada sebuah model.

Untuk mendukung konfigurasi banyak basisdata, Django 1.2 telah menambahkan sebuah atribut `_state` pada instance obyek. Atribut ini akan muncul di `__dict__` untuk sebuah instance model. Jika kode anda bergantung pada perulangan terhadap `__dict__` untuk mengambil daftar dari bidang, anda harus sekarang bersiap untuk menangani atau menyaring atribut `_state`.

### Kode keadaan keluar penjalan percobaan

Kode keadaan keluar dari pejalan percobaan (`tests/runtests.py` dan `python manage.py test`) tidak lagi mewakili angka dari percobaan gagal, karena sebuah kegagalan dari 256 atau percobaan lebih dihasilkan di kode keadaan keluar yang salah. Kode keadaan keluar untuk pejalan percobaan sekarang 0 untuk berhasil (tidak ada kegagalan percobaan) dan 1 untuk angka apapun dari kegagalan percobaan. Jika dibutuhkan, angka kegagalan percobaan dapat ditemukan pada akhir dari keluaran pejalan percobaan.

### Menyandi kue

To fix bugs with cookies in Internet Explorer, Safari, and possibly other browsers, our encoding of cookie values was changed so that the comma and semicolon are treated as non-safe characters, and are therefore encoded as `\054` and `\073` respectively. This could produce backwards incompatibilities, especially if you are storing comma or semi-colon in cookies and have JavaScript code that parses and manipulates cookie values client-side.

### `ModelForm.is_valid()` dan `ModelForm.errors`

Kebanyakan dari pengecekan bekerja untuk ModelForm telah diturunkan ke tingkat model. Sebagai hasilnya, pertama kali anda memanggil `ModelForm.is_valid()`, akses `ModelForm.errors` atau jika tidak memicu pengecekan formulir, mode anda akan dibersihkan di-tempat. Perubahan ini biasanya terjadi ketika model telah disimpan. Jika anda butuh instance tidak dirubah dari model adan, anda harus melewati salinan pada pembangun `ModelForm`.

### `BooleanField` pada MySQL

In previous versions of Django, a model's `BooleanField` under MySQL would return its value as either `1` or `0`, instead of `True` or `False`; for most people this wasn't a problem because `bool` is a subclass of `int` in Python. In Django 1.2, however, `BooleanField` on MySQL correctly returns a real `bool`. The only time this should ever be an issue is if you were expecting the `repr` of a `BooleanField` to print `1` or `0`.

### Perubahan pada penafsiran dari `max_num` di FormSets

Sebagai bagian dari peningkatan dibuat untuk menangani FormSet, nilai awal dan penafsiran dari parameter `max_num` ke fungsi django.forms.formsets.formset_factory() dan django.forms.models.modelformset_factory() telah dirubah sedikit. Perubahan ini juga mempengaruhi cara argumen `max_num` digunakan untuk obyek admin berderet.

Sebelumnya, nilai awalan untuk `max_num` adalah `0` (nol). FormSet kemudian menggunakan nilai boolean dari `max_num` untuk menentukan jika sebuah batasan untuk dikenakan pada sejumlah formulir yang dibangkitkan. Nilai awalan dari `0` berarti bahwa tidak ada batasan awalan pada sejumlah formulir di FormSet.

Dimulai dengan 1.2, nilai awalan untuk `max_num` telah dirubah menjadi `None`, dan FormSet akan berbeda diantara sebuah nilai `None` dan sebuah nilai `0`. Sebuah nilai `None` mengindikasikan bahwa tidak ada batasan pada angka dari formulir yang akan dikenakan; sebuah nilai `0` mengindikasikan bahwa maksimum dari 0 formulir harus dikenakan. Ini tidak berarti bahwa tidak ada formulir akan ditampilkan -- lihat ModelFormSet documentation untuk rincian lebih.

Jika anda secara manual menentukan sebuah nilai dari `0` untuk `max_num`, anda akan butuh memperbaharui FormSet anda dan/atau pengertian admin.

Lihat juga

Penanganan dibantu-JavaScript dari obyek terhubung berderet di admin

### `email_re`

Regular expression tidak terdokumentasi untuk pengecekan alamat surel telah dipindahkan dari `django.form.fields` ke `django.core.validators`. Anda akan butuh memperbaharui impor anda jika anda menggunakannya.

## Fitur usang di 1.2

Akhirnya, Django 1.2 mengusangkan beberapa fitur dari terbitan paling awal. Fitur-fitur ini masih didukung, tetapi akan secara bertahap selama beberapa siklus terbitan selanjutnya.

Kode mengambil keuntungan dari fitur-fitur dibawah akan memunculkan sebuah `PendingDeprecationWarning` di Django 1.2. Peringatan ini akan diam secara awalan, tetapi mungkin menyala menggunakan modul `warnings` Python, atau dengan menjalankan Python dengan sebuah bendera `-Wd` atau `-Wall`.

Di Django 1.3, peringatan ini akan menjadi sebuah `DeprecationWarning`, yang tidak diam. Di Django 1.4 dukungan untuk fitur-fitur ini akan dipindahkan seluruhnya.

Lihat juga

Untuk lebih rinci, lihat dokumentasi pengolahan terbitan Django dan linimasa bantahan.` kami

### Menentukan basisdata

Sebelumnya pada Django 1.2, Django menggunakan sejumlah pengaturan untuk mengendalikan akses ke basisdata tunggal. Django 1.2 memperkenalkan dukungan untuk basisdata banyak, dan sebagai sebuah hasil cara anda menentukan pengaturan basisdata telah berubah.

Tiap pengaturan Django yang ada akan lanjut bekerja sesuai diharapkan sampai Django 1.4. Sampai kemudian pengaturan basisdata gaya-lama akan otomatis diterjemahkan ke bentuk gaya-baru.

Di bentuk gaya-lama (pra 1.2), anda mempunyai sejumlah pengaturan `DATABASE_` di berkas pengaturan anda. Sebagai contoh:

    DATABASE_NAME = "test_db"
    DATABASE_ENGINE = "postgresql_psycopg2"
    DATABASE_USER = "myusername"
    DATABASE_PASSWORD = "s3krit"

Pengaturan ini sekarang di kamus dinamai `DATABASES`. Setiap barang di kamus berhubungan ke hubungan basisdata tunggal, dengan nama `'default'` menggambarkan hubungan basisdata awalan. Nama pengaturan juga diperpendek. Contoh pengaturan sebelumnya akan terlihat seperti ini:

    DATABASES = {
        "default": {
            "NAME": "test_db",
            "ENGINE": "django.db.backends.postgresql_psycopg2",
            "USER": "myusername",
            "PASSWORD": "s3krit",
        }
    }

Ini mempengaruhi pengaturan berikut:

Pengaturan lama | Pengaturan Baru
--- | ---
`DATABASE_ENGINE` | `ENGINE`
`DATABASE_HOST` | `HOST`
`DATABASE_NAME` | `NAME`
`DATABASE_OPTIONS` | `OPTIONS`
`DATABASE_PASSWORD` | `PASSWORD`
`DATABASE_PORT` | `PORT`
`DATABASE_USER` | `USER`
`TEST_DATABASE_CHARSET` | `TEST_CHARSET`
`TEST_DATABASE_COLLATION` | `TEST_COLLATION`
`TEST_DATABASE_NAME` | `TEST_NAME`

Perubahan ini juga dibutuhkan jika anda manual membuat sambungan basisdata menggunakan `DatabaseWrapper()` dari pilihan backend basisdata anda.

Sebagai tambahan pada perubahan di struktur, Django 1.2 memindahkan penanganan khusus untuk backend basisdata siap-pakai. Semua backend basisdata harus sekarang ditentukan oleh sepenuhnya nama modul berkualitas (yaitu, `django.db.backends.postgresql_psycopg2`, daripada hanya `postgresql_psycopg2`).

### Backend basisdata `postgresql`

Pustaka `psycopg1` belum diperbaharui sejak Oktober 2005. Sebagai hasilnya, backend basisdata `postgresql`, yang menggunakan pustaka ini, telah diusangkan.

Jika anda saat ini menggunakan backend `postgresql`, anda harus pindah menggunakan backend `postgresql_psycopg2`. Untuk memperbaharui kode anda, pasang pustaka `psycopg2` dan rubah pengaturan `ENGINE` untuk menggunakan `django.db.backends.postgresql_psycopg2`.

### Middleware menulis kembali-tanggapan CSRF

`CsrfResponseMiddleware`, middleware yang secara otomatis memasukkan token CSRF kedalam formulir `POST` dalam halaman keluar, telah diusangkan mendukung dari sebuah metode etiket cetakan (lihat diatas), dan akan dipindahkan seluruhnya di Django 1.4. `CsrfMiddleware`, yang menyertakan kegunaan dari `CsrfResponseMiddleware` dan `CsrfViewMiddleware`, begitu juga telah diusangkan.

Juga, modul CSRF telah pindah dari bantuan ke inti, dan impor lama telah diusangkan, seperti dijabarkan di catatan peningkatan.

Dokumentasi dipindahkan

Catatan peningkatan telah dipindahkan di dokumen Django saat ini. Silahkan mengacu ke dokumen untuk Django 1.3 atau lebih lama untuk menemukan perintah-perintah ini.

### `SMTPConnection`

Kelas `SMTPConnection` telah diusangkan dalam mendukung dari API backend surel umum. Kode lama yang secara eksplisit sipakai sebuah instance dari sebuah SMTPConnection:

    from django.core.mail import SMTPConnection

    connection = SMTPConnection()
    messages = get_notification_email()
    connection.send_messages(messages)

...should now call `get_connection()` to instantiate a generic email connection:

    from django.core.mail import get_connection

    connection = get_connection()
    messages = get_notification_email()
    connection.send_messages(messages)

Tergantung pada nilai dari pengaturan `EMAIL_BACKEND`, ini mungkin tidak mengembalikan hubungan SMTP. Jika anda secara eksplisit membutuhkan sebuah hubungan SMTP dengan yang mengirim surel, anda dapat secara eksplisit meminta sebuah hubungan SMTP:

    from django.core.mail import get_connection

    connection = get_connection("django.core.mail.backends.smtp.EmailBackend")
    messages = get_notification_email()
    connection.send_messages(messages)

If your call to construct an instance of `SMTPConnection` required additional arguments, those arguments can be passed to the `get_connection()` call:

    connection = get_connection(
        "django.core.mail.backends.smtp.EmailBackend", hostname="localhost", port=1234
    )

### API Pesan Pengguna

API untuk menyimpan pesan-pesan di model `Message` pengguna (melalui `user.message_set.create`) sekarang diusangkan dan akan dipindahkan di Django 1.4 menurut ke standar release process.

Untuk meningkatkan kode anda, anda butuh mengganti instance dari ini:

    user.message_set.create("a message")

...dengan berikut:

    from django.contrib import messages

    messages.add_message(request, messages.INFO, "a message")

Tambahan, jika anda menggunakan metode , anda butuh mengganti berikut:

    for message in user.get_and_delete_messages():
        ...

...dengan:

    from django.contrib import messages

    for message in messages.get_messages(request):
        ...

Untuk informasi lebih, lihat messages documentation penuh. Anda harus mulai memperbaharui kode anda untuk menggunakan API baru segera mungkin.

### Fungsi pembantu bentuk tanggal

`django.utils.translation.get_date_formats()` and `django.utils.translation.get_partial_date_formats()` have been deprecated in favor of the appropriate calls to `django.utils.formats.get_format()`, which is locale-aware when `USE_L10N` is set to `True`, and falls back to default settings if set to `False`.

Untuk mendapatkan bentuk tanggal berbeda, alih-alih menulis ini:

    from django.utils.translation import get_date_formats

    date_format, datetime_format, time_format = get_date_formats()

...gunakan:

    from django.utils import formats

    date_format = formats.get_format("DATE_FORMAT")
    datetime_format = formats.get_format("DATETIME_FORMAT")
    time_format = formats.get_format("TIME_FORMAT")

Atau, ketika secara langsung membentuk sebuah nilai tanggal:

    from django.utils import formats

    value_formatted = formats.date_format(value, "DATETIME_FORMAT")

Hal yang sama berlaku pada global ditemukan di `django.forms.fields`:

- `DEFAULT_DATE_INPUT_FORMATS`

- `DEFAULT_TIME_INPUT_FORMATS`

- `DEFAULT_DATETIME_INPUT_FORMATS`

Gunakan `django.utils.formats.get_format()` untuk mendapatkan bentuk yang sesuai.

### Pejalan percobaan berdasarkan-fungsi

Django 1.2 merubah alat pejalan percobaan untuk menggunakan pendekatan berdasarkan-kelas. Pejalan percobaan berdasarkan fungsi gaya lama akan masih bekerja, tetapi harus diperbaharui untuk menggunakan class-based runners baru.

### `Umpan balik` di `django.contrib.syndication.feeds`

Kelas `django.contrib.syndication.feeds.Feed` telah diganti oleh kelas `django.contrib.syndication.views.Feed`. Kelas `feeds.Feed` lama diusangkan, dan akan dipindakan di Django 1.4.

Kelas baru mempunyai hampir API yang mirip, tetapi mengizinkan instance digunakan sebagai tampilan. Sebagai contoh, pertimbangkan menggunakna kerangka kerja lama di URLconf berikut:

    from django.conf.urls.defaults import *
    from myproject.feeds import LatestEntries, LatestEntriesByCategory

    feeds = {
        "latest": LatestEntries,
        "categories": LatestEntriesByCategory,
    }

    urlpatterns = patterns(
        "",
        # ...
        (
            r"^feeds/(?P<url>.*)/$",
            "django.contrib.syndication.views.feed",
            {"feed_dict": feeds},
        ),
        # ...
    )

Menggunakan kelas Feed, umpan ini dapat disebarkan secara langsung sebagai tampilan:

    from django.conf.urls.defaults import *
    from myproject.feeds import LatestEntries, LatestEntriesByCategory

    urlpatterns = patterns(
        "",
        # ...
        (r"^feeds/latest/$", LatestEntries()),
        (r"^feeds/categories/(?P<category_id>\d+)/$", LatestEntriesByCategory()),
        # ...
    )

Jika anda saat ini menggunakan tampilan `feed()`, kelas `LatestEntries` akan sering tidak butuk dirubah sebagian dari mensubkelaskan kelas `Feed` baru. Pengecualian adalah jika Django otomatis bekerja dengan nama dari cetakan untuk digunakan membangun gambaran umpan dan judul unsur (jika anda tidak sedang menentukan atribut `title_template` dan `description_template`). Anda harus memastikan bahwa anda selalu menentukan atribut `title_template` dan `description_template`, atau menyediakan metode `item_title()` and `item_description()`.

Bagaimanapun, `LatestEntriesByCategory` menggunakan metode `get_object()` dengan argumen `bits` untuk menentukan kategori khusus untuk ditampilkan. Di kelas `Feed` baru, metode `get_object()` mengambil sebuah `request` dan argumen dari URL, jadi itu akan terlihat seperti ini:

    from django.contrib.syndication.views import Feed
    from django.shortcuts import get_object_or_404
    from myproject.models import Category

    class LatestEntriesByCategory(Feed):
        def get_object(self, request, category_id):
            return get_object_or_404(Category, id=category_id)

        # ...

Tambahannya, metode `get_feed()` pada kelas-kelas `Feed` sekarang mengambil argumen berbeda, yang mungkin mempengaruhi anda jika anda menggunakan kelas-kelas `Feed`. Daripada hanya mengambil sebuah pilihan argumen `url`, itu sekarang dapat mengambil dua argumen: obyek dikembalikan oleh metode `get_object()` itu sendiri, dan obyek `request` saat ini.

Untuk memperhitungkan kelas-kelas `Feed` tidak sedang diinisialisasi untuk setiap permintaan, metode `__init__()` sekarang tidak mengambil argumen secara awalan. Sebelumnya itu akan mengambil `slug` dari URL dan obyek `request`.

Sesuai dengan RSS best practices, umpan RSSakan sekarang menyertakan sebuah unsur `atom:link`. Anda mungkin butuh untuk memperbaharui percobaan anda untuk mengambil ini kedalam akun.

Untuk informasi lebih, lihat syndication framework documentation penuh.

### ID pesan teknis

Sampai versi 1.1 Django menggunakan ID pesan teknis untuk menyediakan pelokalan kemungkinan untuk menterjemahkan bentuk tanggal dan waktu. Mereka dapat diterjemahkan translation strings yang dapat dikenali karena mereka semua huruf besar (sebagai contoh `DATETIME_FORMAT`, `DATE_FORMAT`, `TIME_FORMAT`). Mereka telah diusangkan dalam mendukung infrastruktur Bentuk lokalisasi baru yang mengizinkan pelokal menentukan bahwa informasi di sebuah berkas `formats.py` di direktori `django/conf/locale/<locale name>/` sama.

### GeoDjango

To allow support for multiple databases, the GeoDjango database internals were changed substantially. The largest backwards-incompatible change is that the module `django.contrib.gis.db.backend` was renamed to `django.contrib.gis.db.backends`, where the full-fledged spatial database backends now exist. The following sections provide information on the most-popular APIs that were affected by these changes.

#### `SpatialBackend`

Prior to the creation of the separate spatial backends, the `django.contrib.gis.db.backend.SpatialBackend` object was provided as an abstraction to introspect on the capabilities of the spatial database. All of the attributes and routines provided by `SpatialBackend` are now a part of the `ops` attribute of the database backend.

Modul lama `django.contrib.gis.db.backend` masih disediakan untuk akses kesesuaian-kebelakang pada sebuah obyek `SpatialBackend`, yang hanya sebuah nama lain pada modul `ops` dari awalan hubungan basisdata spasial.

Pengguna yang bergantung pada modul tidak terdokumentasi dan obyek dalam `django.contrib.gis.db.backend`, daripada abstraksi disediakan oleh `SpatialBackend`, dibutuhkan untuk merubah kode mereka. Sebagai contoh, impor berikut akan bekerja di 1.1 dan dibawah:

    from django.contrib.gis.db.backend.postgis import PostGISAdaptor

Akan perlu dirubah:

    from django.db import connection

    PostGISAdaptor = connection.ops.Adapter

#### Model `SpatialRefSys` dan `GeometryColumns`.

Di versi sebelumnya dari GeoDjango, `django.contrib.gis.db.models` mempunyai model `SpatialRefSys` dan `GeometryColumns` untuk meminta metadata spasial OGC tabel `spatial_ref_sys` dan `geometry_columns`, masing-masing.

Selagi nama lain ini masih disediakan, mereka hanya untuk awalan hubungan basisdata dan hanya yang ada jika hubungan awalan menggunakan backend basisdata spasial terdukung.

Catatan

Because the table structure of the OGC spatial metadata tables differs across spatial databases, the `SpatialRefSys` and `GeometryColumns` models can no longer be associated with the `gis` application name. Thus, no models will be returned when using the `get_models` method in the following example:

    >>> from django.db.models import get_app, get_models
    >>> get_models(get_app("gis"))
    []

To get the correct `SpatialRefSys` and `GeometryColumns` for your spatial database use the methods provided by the spatial backend:

>     >>> from django.db import connections
>     >>> SpatialRefSys = connections["my_spatialite"].ops.spatial_ref_sys()
>     >>> GeometryColumns = connections["my_postgis"].ops.geometry_columns()

Catatan

Ketika menggunakan model dikembalikan dari metode `spatial_ref_sys()` dan `geometry_columns()`, anda masih dapat menggunakan nama lain basisdata yang tepat ketika meminta pada hubungan bukan-awalan. Dengan kata lain, untuk memastikan bahwa model di contoh diatas menggunakan basisdata tepat:

    sr_qs = SpatialRefSys.objects.using("my_spatialite").filter(...)
    gc_qs = GeometryColumns.objects.using("my_postgis").filter(...)

### Kode bahasa `no`

Kode bahasa yang digunakan saat ini untuk Norwegia Bokmål 11no11 sedang diganti oleh kode bahasa lebih umum `nb`.

### Pemuat cetakan berdasarkan fungsi

Django 1.2 merubah mekanisme pemuat cetakan untuk menggunakan pendekatan berdasarkan-kelas. Pemuat cetakan berdasarkan-fungsi gaya lama akan amsih bekerja, tetapi harus diperbaharui untuk menggunakan pemuat cetakan berdasarkan kelas yang baru.