# dokumentasi Django 2.2.9.dev20191202104323

# Catatan terbitan Django 1.5

Februari 26, 2013

Selamat datang di Django 1.5!

Catatan terbitan ini mencangkupi new features, sama halnya beberapa backwards incompatible changes anda akan ingin menjadi waspada ketika meningkatkan dari Django 1.4 atau versi terlama. Kami telah membuang beberapa fitur, yang rinciannya di our deprecation plan, dan kami telah begun the deprecation process for some features.

## Ikhtisar

Fitur baru terbesar di Django 1.5 adalah configurable User model. Sebelum Django 1.5, aplikasi yang menginginkan menggunakan kerangka kerja otentifikasi Django (`django.contrib.auth`) dipaksa untuk menggunakan pengertian Django dari "user". Di DJango 1.5, anda sekarang dapat menukar model `User` untuk satu yang anda tulis sendiri. Ini dapat menjadi sebuah perpanjangan sederhana pada model `User` yang ada -- sebagai contoh, anda dapat menambah sebuah bidang ID Twitter atau Facebook -- atau anda dapat secara lengkap mengganti `User` dengan satu seluruhnya disesuaiakan untuk situs anda.

Django 1.5 juga terbitan pertama dengan Python 3 support! Kami sedang melabelkan dukungan ini "experimental" karena kami belum mempertimbangkan itu siap-produksi, tetapi semuanya di tempat untuk anda memulai menghubungkan aplikasi anda ke Python 3. Terbitan kami selanjutnya, Django 1.6, akan mendukung Python 3 tanpa pemesanan.

Fitur baru penting lainnya di Django 1.5 termasuk:

- Support for saving a subset of model's fields - `Model.save()` sekarang menerima sebuah argumen `update_fields`, membiarkan anda menentukan bidang-bidang mana ditulis kembali ke basisdata ketika anda memanggil `save()`. Ini dapat membantu di operasi tinggi-berbarengan, dan dapat memperbaiki penampilan.
- Lebih baik support for streaming responses melalui kelas tanggapan `StreamingHttpResponse` baru.
- GeoDjango sekarang mendukung PostGIS 2.0.
- ... dan lebih; ... and more; see below.

Dimanapun memungkinkan kami mencoba memperkenalkan fitur baru di sikap bertentangan kebelakang per kebijakan our API stability policy. Bagaimanapun, seperti dengan terbitan sebelumnya, Django 1.5 dibekali dengan beberapa backwards incompatible changes kecil; orang meningkatkan dari versi sebelumnya dari Django harus membaca daftar itu hati-hati.

Satu fitur diusangkan yang perlu dicatat adalah bergeser ke etiket "new-style" `url`. Sebelum pada Django 1.3, sintaksis seperti `{% url myview %}` telah ditafsirkan tidak benar (Django menganggap `"myview"` menjadi nama harfiah dari sebuah tampilan, bukan sebuah variabel cetakan bernama `myview`). Django 1.3 dan diatasnya memperkenalkan sintaksis `{% load url from future %}` untuk membawa perilaku diperbaiki `myview` telah dilihat sebagai sebuah variabel.

Hasil dari ini adalah bahwa jika anda tidak menggunakan `{% load url from future %}` di cetakan anda, anda akan butuh merubah etiket seperti `{% url myview %}` menjadi `{% url "myview" %}`. Jika anda sedang menggunakan `{% load url from future %}` anda dapat cukup memindahkan baris itu dibawah Django 1.5

## Kesesuaian Python

Django 1.5 membutuhkan Python 2.6.5 atau diatas, meskipun kami sangat menganjurkan Python 2.7.3 atau diatas. Dukungan untuk Python 2.5 dan dibawah telah dibuang.

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

Django 1.5 tidak berjalan pada Jython terbitan akhir, karena terbitan terakhir Jython tidak saat ini mendukung Python 2.6. Bagaimanapun, Jython saat ini tidak menawarkan terbitan alpha menampilkan dukungan 2.7, dan Django 1.5 mendukung terbitan alpha tersebut.

### Mendukung Python 3

Django 1.5 memperkenalkan dukungan untuk Python 3 - secara khusus, Python 3.2 dan diatas. Ini datang di bentuk dasar kode tunggal; anda tidak butuh memasang versi berbeda dari Django di Python 3. Ini berarti bahwa anda dapat menulis aplikasi disasar untuk hanya Python 2, hanya Python 3, atau aplikasi tunggal yang mendukung kedua serambi.

Bagaimanapun, kami sedang melabelkan dukungan "experimental" ini untuk sekarang: meskipun itu menerima percobaan panjang melalui deretan percobaan otomatis kami, itu menerima sangat sedikit percobaan dunia-nyata. Kami telah melakukan yang terbaik untuk mengurangi kesalahan, tetapi kami tidak dapat memastikan kami mencangkupi semua kemungkinan penggunaan Django.

Beberapa fitur dari Django tidak tersedia karena mereka tergantung pada perangkat lunak pihak-ketiga yang belum dihubungkan ke Pyhton 3, termasuk:

- Backend basisdata MySQL (tergantung pada MySQLdb)
- `ImageField` (tergantung pada PIL)
- `LiveServerTestCase` (tergantung pada Selenium WebDriver)

Lebih jauh, Django lebih dari sekedar kerangka kerja jaringan; itu adalah sebuah ekosistem komponen dapat ditanam. Pada titik ini, sangat sedikit aplikasi pihak-ketiga telah dihubungkan ke Python 3, jadi itu tidak mungkin bahwa aplikasi dunia-nyata akan mempunyai semua ketergantungannya terpuaskan dibawah Python 3.

Dengan demikian, kami menganjurkan bahwa Django 1.5 tidak digunakan dalam produksi dibawah Python 3. Sebagai gantinya, gunakan kesempatan ini untuk memulai penghubungan aplikasi-aplikasi ke Python 3. Jika anda seorang penulis dari sebuah komponen tertanam, kami mendorong anda memulai penghubungan sekarang.

Kami berencana untuk menawarkan kelas-pertama, dukunagn siap-produksi untuk Python 3 di terbitan kami selanjutnya, Django 1.6.

## Apa yang baru di Django 1.5

### Model User Dikonfigurasi

Dalam Django 1.5, anda sekarang dapat menggunakan model anda sendiri sebagai penyimpanan untuk data terkait-pengguna. Jika proyek anda butuh nama pengguna lebih dari 30 karakter, atau jika anda ingin menyimpan nama pengguna dalam bentuk lainnya dari pada nama pertama/nama terakhir, atau anda ingin menaruh informasi profil penyesuaian kedalam obyek User anda, anda dapat sekarang melakukannya.

Jika anda mempunyai aplikasi dapat digunakan kembali pihak-ketiga yang mengacu model User, anda mungkin butuh membuat beberapa perubahan ke cara anda mengacu instance User. Anda harus juga mendokumentasikan fitur khusus apapun dari model User yang aplikasi anda bergantung.

Lihat documentation on custom user models untuk lebih rinci.

### Mendukung untuk menyimpan subset dari bidang model

Cara `Model.save()` mempunyai argumen kata kunci baru `update_fields`. Dengan menggunakan argumen ini itu memungkinkan menyimpan hanya memilih daftar bidang model. Ini dapat berguna untuk alasan penampilan atau ketika mencoba menghindari perubahan penimpaan bersama-sama.

Instance yang ditunda (itu dimuat oleh `.only()` atau `.defer()`) akan otomatis menyimpan hanya bidang yang dimuat. Jika bidang apapun disetel secara manual setelah dimuat, bidang itu akan juga mendapatkan terperbaharui pada penyimpanan.

Lihat dokumentasi `Model.save()` untuk lebih rinci.

### Menyimpan sementara dari instance model terkait

Ketika melintasi hubungan, ORM akan menghindari mengambil kembali obyek yang sebelumnya dimuat. Sebagai contoh, dengan model tutorial:

    >>> first_poll = Poll.objects.all()[0]
    >>> first_choice = first_poll.choice_set.all()[0]
    >>> first_choice.poll is first_poll
    True

Di Django 1.5, baris ketiga tidak lagi membangkitkan permintaan SQL baru untuk mengambil `first_choice.poll`; itu telah disetel oleh baris kedua.

Untuk hubungan one-to-one, kedua sisi dapat disimpan. Untuk hubungan many-to-one, hanya sisi tunggal dari hubungan dapat disimpan. Ini terutama sangat membantu di perpaduan dengan `prefetch_related`.

### Secara eksplisit mendukung tanggapan mengalir

Sebelum Django 1.5, itu memungkinkan membuat tanggapan mengalir dengan melewatkan sebuah perulangan pada `HttpResponse`. Tetapi ini tidak handal: middleware apapun yang mengakses atribut `content` akan memakan perulangan secara dini.

Anda dapat secara eksplisit membangkitkan tanggapan mengalir dengan kelas `StreamingHttpResponse` baru. Kelas ini membuka atribut `streaming_content` yang merupakan sebuah perulangan.

Sejak `StreamingHttpResponse` tidak mempunyai atribut `content`, middleware yang butuh mengakses ke isi tanggapan harus mencoba untuk tanggapan mengalir dan berperilaku sesuai.

### Etiket cetakan `{% verbatim %}`

Untuk membuatnya lebih mudah berurusan dengan cetakan JavaScript yang bertabrakan dengan sintaksis Django, anda dapat sekarang menggunakan etiket blok `verbatim` untuk menghindari mengurai isi etiket.

### Pengambilan dari instance `ContentType` terkait dengan model proxy

Metode `ContentTypeManager.get_for_model()` dan `ContentTypeManager.get_for_models()` mempunyai argumen kata kunci baru -- masing-masing `for_concrete_model` dan `for_concrete_models`. Dengan melewatkan `False` menggunakan argumen ini itu sekarang memungkinkan mengambil `ContentType` terkait dengan model proxy

### Variabel `view` baru di konteks tampilan berdasarkan-kelas

Di semua generic class-based views (atau tampilan berdasarkan-kelas apapun warisan dari `ContextMixin`), kamus konteks mengandung sebuah variabel `view` yang menunjuk ke instance `View`.

### GeoDjango

- Obyek GEOS `LineString` dan `MultiLineString` sekarang mendukung metode `interpolate()` dan `project()` (disebut acuan segaris).
- Sifat `wkb` dan `hex` dari obyek `GEOSGeometry` menjaga dimensi Z.
- Dukungan untuk PostGIS 2.0 telah ditambahkan dan dukungan untuk GDAL < 1.5 telah dibuang.

### Tutorial baru

Tambahan pada dokumen menyertakan Tutorial 3 dirubah dan tutorial on testing baru. Bagian baru, "Advanced Tutorials", menawarkan How to write reusable apps dan juga panduan langkah-demi-langkah untuk pembantu baru di Writing your first patch for Django.

### Fitur kecil

Django 1.5 juga menyertakan beberapa perbaikan kecil yang tidak berharga:

- Mesin cetakan sekarang mengartikan `True`, `False` dan `None` sebagai obyek Python sesuai.

- `django.utils.timezone` menyediakan pembantu untuk merubah datetime sadar diantara zona waktu. Lihat `localtime()`.

- Tampilan umum mendukung permintaan OPTION.

- Perintah pengelolaan tidak memunculkan `SystemExit` lagi ketika dipanggil oleh kode dari `call_command()`. Pengecualian apapun dimunculkan oleh perintah (kebanyakan `CommandError`) adalah diperbanyak.

  Bahkan, ketika anda mengelurkan kesalahan atau pesan di perintah penyesuaian anda, anda harus sekarang menggunakan `self.stdout.write('message')` and `self.stderr.write('error')` (lihat catatan pada management commands output).

- The `dumpdata` management command outputs one row at a time, preventing out-of-memory errors when dumping large datasets.

- Jika localflavor untuk Canada, "pq" telah ditambahkan pada kode diterima untuk Quebec. Itu adalah singkatan lama.

- Penghias receiver sekarang dapat terhubung ke lebih dari satu sinyal dengan menyokong daftar sinyal.

- Di admin, anda sekarang dapat menyaring pengguna berdasarkan keanggotaan mereka.

- `QuerySet.bulk_create()` sekarang mempunyai sebuah argumen batch_size. Secara awalan batch_size tidak terbatas kecuali untuk SQLite dimana kumpulan tunggal terpada sehingga parameter 888 per permintaan tidak melebihi.

- Pengaturan `LOGIN_URL` dan `LOGIN_REDIRECT_URL` sekarang juga menerima tampilan nama fungsi dan named URL patterns. Ini mengizinkan anda mengurangi penggandaan konfigurasi. Informasi lebih dapat ditemukan di dokumentasi `login_required()`.

- Django sekarang menyediakan mod_wsgi auth handler.

- `QuerySet.delete()` dan `Model.delete()` sekarang dapat mengambil jalur-cepat di beberapa kasus. Jalur-cepat mengizinkan untuk sedikit permintaan dan sedikit obyek diambil kedalam memori. Lihat `QuerySet.delete()` untuk rincian.

- Sebuah instance dari `ResolverMatch` disimpan pada permintaan sebagai `resolver_match`.

- Secara awalan, semua pencatatan pesan mencapat pencatat `django` ketika `DEBUG` adalah ``True``dikirim ke konsol (meskipun anda menentukan kembali pencatat di pengaturan `LOGGING` anda).

- Ketika menggunakan `RequestContext`, itu memungkinkan mencari perizinan dengan menggunakan `{% if 'someapp.someperm' in perms %}` di cetakan.

- Itu tidak dibutuhkan lagi memiliki cetakan `404.html` dan `500.html` di akar direktori cetakan. Django akan mengeluarkan beberapa pesan kesalahan untuk kedua keadaan ketika cetakan tersebut tidak ditemukan. Tentu saja, itu masih dianjurkan sebagai latihan bagus untuk menyediakan cetakan tersebut untuk menampilkan halaman kesalahan cantik ke pengguna.

- `django.contrib.auth` menyediakan sinyal bau yang dikeluarkan ketika pengguna gagal untuk berhasil masuk. Lihat `user_login_failed`

- Pilihan `loaddata --ignorenonexistent` baru mengabaikan data untuk bidang yang tidak lagi ada.

- Tuntutan baru `assertXMLEqual()` dan `assertXMLNotEqual()` mengizinkan anda untuk mencoba persamaan untuk isi XML pada tingkat semantik, tanpa peduli untuk perbedaan sintaksis (spasi, urutan atribut, dll.).

- RemoteUserMiddleware sekarang memaksa keluar ketika kepala REMOTE_USER hilang selama sesi peramban sama.

- cache-based session backend dapat menyimpan data sesi di tembolok bukan-awalan.

- Indeks banyak-kolom sekarang dapat dibuat pada model. Baca dokumentasi `index_together` untuk informasi lebih.

- Selama konfigurasi pencatatan peringatan Pengusangan bertele-tele diadakan dan peringatan ditangkap kedalam sistem pencatatan. Peringatan tercatat dirutekan melalui penangan pencataan `console`, yang secara awalan membutuhkan `DEBUG` menjadi True untuk keluaran menjadi dibangkitkan. Hasil adalah DeprecationWarning harus dicetak ke console dalam lingkungan pengembangan cara mereka telah di versi Python < 2.7.

- API untuk metode `django.contrib.admin.ModelAdmin.message_user()` tekah dirubah untuk kemampuan menerima argumen tambahan mirip pada `django.contrib.messages.add_message()`. Ini sangat berguna untuk membangkitkan pesan kesalahan dari tindakan admin.

- Daftar penyaring admin sekarang dapat disesuaiakan per-permintaan terima kasih pada metode `django.contrib.admin.ModelAdmin.get_list_filter()` baru.

## Perubahan bertentangan kebelakang di 1.5

Peringatan

Sebagai tambahan pada perubahan diuraikan di bagian ini, pastikan untuk meninjau kembali deprecation plan untuk setiap fitur yang telah dipindahkan. Jika anda belum memperbaharui kode anda dalam linimasa pengusangan untuk fitur yang diberikan, perpindahannya mugkin muncul sebagai perubahan ketidaksesuaian kebelakang.

### `ALLOWED_HOSTS` dibutuhkan dalam produksi

Pengaturan `ALLOWED_HOSTS` baru mensahkan kepala `Host` permintaan dan melindungi terhadap serangan host-poisoning. Pengaturan ini sekarang wajib kapanpun `DEBUG` adalah `False`, atau `django.http.HttpRequest.get_host()` lain akan memunculkan `SuspiciousOperation`. Untuk lebih rinci lihat `full documentation` untuk pengaturan baru.

### Pengelola pada model abstrak.

Model-model abstrak dapat menentukan pengelola penyesuaian, dan pengelola itu will be inherited by any concrete models extending the abstract model. Bagaimanapun, jika anda mencoba menggunakan model abstrak untuk memanggil sebuah metode pada pengelola, sebuah pengecualian sekarang akan dimunculkan. Sebelumnya, panggilan telah diizinkan, tetapi akan gagal segera setelah tindakan basisdata apapun telah diusahakan (biasanya dengan sebuah kesalahan "tabel tidak ada" dari basisdata).

Jika anda mempunyai kegunaan pada pengelola yang anda telah minta menggunakan kelas abstrak, anda harus pindah logika tersebut ke `staticmethod` Python atau `classmethod` pada kelas abstrak.

### Konteks di arsip tahun tampilan berdasarkan-kelas

Untuk kemantapan dengan tampilan umum berdasarkan-tanggal lainnya, `YearArchiveView` sekarang melewatkan `year` dalam konteks sebagai `datetime.date` daripada sebuah string. Jika anda sedang menggunakan `{{ year }}` dalam cetakan anda, anda harus mengganti itu dengan `{{ year|date:"Y" }}`.

`next_year` dan `previous_year` juga ditambahkan dalam konteks. Mereka dihitung berdasarkan pada `allow_empty` dan `allow_future`.

### Konteks dalam arsip tahun dan bulan tampilan berdasarkan-kelas

`YearArchiveView` dan `MonthArchiveView` didokumentasikan untuk menyediakan urutan `date_list` dalam urutan menurun. Dalam 1.5, urutan dokumentasi telah disimpan kembali. Anda mungkin ingin menambah (atau memindahkan) katakunci `reversed` ketika anda sedang mengulang pada `date_list` di cetakan:

    {% for date in date_list reversed %}

`ArchiveIndexView` maish menyediakan `date_list` di urutan menurun.

### Konteks dalam TemplateView

Untuk kemantapan dengan rancangan dari tampilan umum lain, `TemplateView` tidak lagi melewatkan kamus `params` kedalam konteks, sebagai gantinya melewati variabel dari URLconf secara langsung kedalam konteks.

### Data bukan-formulir dalam permintaan HTTP

`request.POST` akan tidak lagi menyertakan data ditempatkan melalui permintaan HTTP dengan content-types bukan bentuk-khusus di kepala. Di versi sebelumnya, data ditempatkan dengan content-types daripada `multipart/form-data` atau `application/x-www-form-urlencoded` akan masih mengakhiri diwakili di atribut `request.POST`. Pengembang berharap mengakses ke data POST mentah untuk kasus ini, harus menggunakan atribut `request.body` sebagai gantinya.

### Sinyal `request_finished`

Django terbiasa mengirim sinyal `request_finished` segera setelah fungsi tampilan mengembalikan sebuah tanggapan. Ini berinteraksi buruk dengan streaming responses yang menunda pembangkitan isi.

Sinyal ini sekarang terkirim setelah isi sepenuhnya dikonsumsi oleh pintu gerbang WSGI. Ini mungkin bertentangan kebelakang jika anda mengandalkan pada sinyal sedang dinyalakan sebelum mengirim isi tanggapan ke klien. Jika anda lakukan, anda harus mempertimbangkan menggunakan middleware sebagai gantinya.

Catatan

Beberapa peladen WSGI dan middleware tidak selalu memanggil `close` pada obyek tanggapan setelah menangani sebuah permintaan, kebanyakan terutama uWSGI sebelum 1.2.6 dan middleware pelaporan kesalahan Sentry sampai 2.0.7. Di kasus tersebut sinyal `request_finished` tidak dikirim sama sekali. Ini dapat menghasilkan sebuah hubungan diam ke basisdata dan peladen memcache.

### Permintaan OPTIONS, PUT dan DELETE di klien percobaan

Tidak seperti GET dan POST, metode HTTP ini tidak diterapkan oleh peramban jaringan. Sebaliknya mereka digunakan dalam API, yang memindahkan data dalam beragam bentuk seperti JSON atau XML. Sejak permintaan itu mungkin mengandung data yang berubah-ubah, Django tidak berusaha menyandi badan mereka.

Bagaimanapun, klien percobaan terbiasa membangun sebuah permintaan deretan karakter untuk permintaan OPTIONS dan DELETE seperti untuk GET, dan sebuah badan permintaan seperti untuk POST. Penyandian ini adalah berubah-ubah dan tidak tetap dengan perilaku Django ketika itu menerima permintaan, jadi itu telah dipindahkan di Django 1.5.

Jika anda sedang menggunakan parameter `data` dalam sebuah permintaan OPTION atau DELETE, anda harus merubahnya menjadi permintaan deretan karakter dan menambahkannya ke parameter `path`.

Jika anda sedang menggunakan parameter `data` dalam sebuah permintaan PUT tanpa `content_type`, anda harus menyandi data anda sebelum melewatkannya ke klien percobaan dan menyetel argumen `content_type`.

### Versi sistem dari `simplejson` tidak lagi digunakan

As explained below, Django 1.5 mengusangkan `django.utils.simplejson` dalam mendukung modul `json` siap-pakai Python 2.6. Dalam teori, perubahan ini tidak berbahaya. Sayangnya, karena ketidaksesuaian diantara versi dari `simplejson`, itu mungkin membangkitkan kesalahan di beberapa keadaan.

Fitur terkait-JSON di Django 1.4 selalu menggunakan `django.utils.simplejson`. Modul ini adalah sebenarnya:

- Versi sistem dari `simplejson`, jika satu telah tersedia (yaitu `import simplejson` bekerja), jika itu lebih sering dari salinan siap-pakai Django atau itu mempunyai pemercepat C, atau
- Modul `json` dari pustaka standar, jika itu telah tersedia (yaitu Python 2.6 atau lebih besar), atau
- Sebuah salinan siap-pakai dari versi 2.0.7 dari `simplejson`.

Di Django 1.5, fitur itu menggunakan modul `json` Python, yang berdasarkan pada versi 2.0.9 dari `simplejson`.

Ada ketidakkesesuaian tidak dikenal diantara salinan Django versi 2.0.7 dan salinan Python versi 2.0.9. Bagaimanapun, ada beberapa ketidak sesuaian diantara versi lain dari `simplejson`:

- While the `simplejson` API is documented as always returning unicode strings, the optional C implementation can return a bytestring. This was fixed in Python 2.7.
- `simplejson.JSONEncoder` mendapatkan sebuah argumen kata kunci `namedtuple_as_object` di versi 2.2.

More information on these incompatibilities is available in ticket #18023.

Hasil bersih adalah bahwa, jika anda telah memasang `simplejson` dan kode anda menggunakan serialisasi Django internal secara langsung -- sebagai contoh `django.core.serializers.json.DjangoJSONEncoder`, pergantian dari `simplejson` ke `json` dapat merusak kode anda. (Pada umumnya, perubahan pada internal tidak didokumentasikan; kami sedang membuat sebuah pengecualian disini.)

Pada titik ini, perawat Django percaya bahwa menggunakan `json` dari pustaka standar menawarkan jaminan paling kuat dari kesesuaian-kebelakang. Mereka mengajurkan menggunakannya dari sekarang.

### Jenis deretan karakter dari parameter metode pengacak

If you have written a custom password hasher, your `encode()`, `verify()` or `safe_summary()` methods should accept Unicode parameters (`password`, `salt` or `encoded`). If any of the hashing methods need bytestrings, you can use the `force_bytes()` utility to encode the strings.

### Pemeriksaan dari previous_page_number dan next_page_number

Ketika menggunakan metode object pagination, `previous_page_number()` dan `next_page_number()` dari obyek `Page` tidak memeriksa jika nomor yang dikembalikan didalam jangkauan halaman yang ada. Itu melakukan pemeriksaan itu sekarang dan memunculkan pengecualian `InvalidPage` ketika nomornya terlalu kecil atau terlalu tinggi.

### Perilaku pilihan basisdata perbaikan otomatis pada PostgreSQL berubah

Pilihan perbaikan otomatis PostgreSQL tidak bekerja seperti dinyatakan sebelumnya. Itu bekerja untuk blok transaksi tunggal, tetapi setelah blok pertama meninggalkan perilaku perbaikan otomatis tidak pernah disimpan kembali. Kesalahan ini sekarang diperbaiki di 1.5. Selagi ini hanya sebuah perbaikan kesalahan, itu adalah berharga memeriksa perilaku aplikasi anda jika anda sedang menggunakan PostgreSQL bersama-sama dengan pilihan perbaikan otomatis.

### Sesi tidak menyimpan pada 500 tanggapan

Sesi middleware Django akan melewati menyimpan sesi data jika kode keadaan tanggapan adalah 500.

### Pemeriksaan surel pada admin masuk gagal

Sebelum Django 1.5, jika anda berusaha masuk kedalam antarmuka admin dan salah menggunakan alamat surel anda daripada nama pengguna, antarmuka admin akan menyediakan sebuah peringatan menyarankan bahwa alamat surel anda bukan nama pengguna anda. Dalam Django 1.5, perkenalan dari custom user models telah mewajibkan perpindahan peringatan ini. Ini tidak merubah perilaku masuk dari situs admin; itu hanya mempengaruhi pesan peringatan yang ditampilkan dibawah satu suasana tertentu dari kegagalan masuk.

### Perubahan di pengerjaan percobaan

Beberapa perubahan telah diperkenalkan di pengerjaan dari percobaan yang mungkin ketidaksesuaian-kebelakang untuk beberapa penyetelan percobaan:

#### Basisdata mengalir di `django.test.TransactionTestCase`

Sebelumnya, percobaan basisdata telah dipotong sebelum setiap percpbaan berjalan di `TransactionTestCase`.

Untuk dapat menjalankan unit percobaan di setiap urutan dan memastikan mereka selalu terpencil dari setiap lainnya. `TransactionTestCase` akan sekarang menyetel kembali basisdata setelah setiap percobaan berjalan.

#### Tidak ada lagi tersirat menyetel kembali urutan DB

Percobaan `TransactionTestCase` digunakan untuk menyetel kembali urutan primary key secara otomatis bersama-sama dengan tindakan membilas basisdata digambarkan diatas.

Ini telah dirubah sehingga tidak ada urutan secara mutlak disetel kembali. Ini dapat menyebabkan percobaan `TransactionTestCase` yang tergantung pada nilai primay key kode-keras rusak.

Atribut `reset_sequences` baru dapat digunakan untuk memaksa perilaku lama untuk `TransactionTestCase` yang mungkin membutuhkannya.

#### Urutan dari percobaan

Untuk memastikan semua kode `TestCase` mulai dengan basisdata bersih, percobaan sekarang dijalankan di urutan berikut:

- First, all unit tests (including `unittest.TestCase`, `SimpleTestCase`, `TestCase` and `TransactionTestCase`) are run with no particular ordering guaranteed nor enforced among them.
- Kemudian setiap percobaan lainnya (sebagai contoh doctests) yang mengubah basisdata tanpa menyimpan kembali dia ke keadaan aslinya berjalan.

Ini seharusnya tidak menyebabkan masalah apapun meskipun anda mempunyai dokumen percobaan yang ada yang mengganggap `TransactionTestCase` dijalankan lebih awal meninggalkan beberapa keadaan basisdata dibelakang atau unit percobaan yang bergantung pada beberapa bentuk dari keadaan menjadi diawetkan setelah pengerjaan dari percobaan lain. Percobaan tersebut sudah sangat rapuh, dan hrus sekarang dirubah untuk dapat berjalan secara berdiri sendiri.

### Kamus cleaned_data menjaga untuk formulir tidak sah.

Kamus `cleaned_data` sekarang selalu hadir setelah pengesahan formulir. Ketika formulir tidak disahkan, itu hanya mengandung bidang yang melewatkan pengesahan. Anda harus mencoba keberhasilan dari pengesahan dengan metode `is_valid()` dan bukan dengan kehadiran atau ketidakhadiran dari atribut `cleaned_data` di formulir.

### Perilaku dari `syncdb` dengan banyak basisdata

`syncdb` sekarang meminta perute basisdata untuk menentukan jika jenis isi (ketika `contenttypes` adalah diadakan) dan perizinan (ketika `auth` adalah diadakan) harus dibuat di basisdata sasaran. Sebelumnya, itu membuat mereka di basisdata awalan, bahkan ketika basisdata lain telah ditentukan dengan pilihan `--database`.

Jika anda menggunakan `syncdb` pada banyak basisdata, anda harus memastikan bahwa perute mengizinkan menyeimbangkan jenis isi dan perizinan untuk hanya satu dari mereka. Lihat dokumentasi di behavior of contrib apps with multiple databases untuk informasi lebih.

### Deserial XML tidak akan mengurai dokumen dengan DTD

Untuk mencegah pembukaan pada serangan denial-of-service terkait pada acuan entitas eksternal dan perpanjangan entitas, deserial model XML sekarang menolak mengurai XML dokumen mengandung sebuah DTD (DOCTYPE definition). Sejak penserial XML tidak mengeluarkan DTD, ini tidak akan berdampak penggunaan khusus, hanya kasus-kasus dimana dokumen XML dibuat-penyesuaian yang dilewatkan ke deserial model Django .

### Awalan formset `max_num`

Sebuah nilai (awalan) dari `None` untuk argumen `max_num` pada pabrik formset awalan tidak lagi untuk mengizinkan angka apapun dari formulir di formset. Malahan, untuk mencegah serangan kelelahan-memori, itu sekarang awalan ke batasan dari 1000 formulir. Batasan ini dapat dimunculkan dengan tegas mengatur nilai tertinggi untuk `max_num`.

### Bermacam-macam

- `django.forms.ModelMultipleChoiceField` sekarang mengembalikan sebuah `QuerySet` kosong sebagai nilai kosong daripada sebuah daftar kosong.
- `int_to_base36()` sebagaimana mestinya memunculkan `TypeError` sebagai gantinya dari `ValueError` untuk masukan bukan-integer
- The `slugify` template filter is now available as a standard Python function at `django.utils.text.slugify()`. Similarly, `remove_tags` is available at `django.utils.html.remove_tags()`.
- Berkas-berkas terunggah tidak lagi dibuat sebagai dapat dijalankan secara awalan. Jika anda butuh mereka untuk menjadi dapat dijalankan rubah `FILE_UPLOAD_PERMISSIONS` ke kebutuhan anda. Nilai awalan baru adalah `0o666` (octal) dan nilai umask saat ini adalah pertama yang disembunyikan.
- `F expressions` mendukung penghubung bitwise berdasarkan `&` and `|`. Penghubung ini sekarang tersedia menggunakan `.bitand()` and `.bitor()`. Perpindahan dari `&` and `|` telah selesai untuk menjadi tetap dengan Q() expressions dan `QuerySet` memadukan dimana penghubung digunakan sebagai boolean penghubung AND dan OR.
- Dalam panggilan `filter()`, ketika `F expressions` mengandung pencarian mencangkup hubungan banyak-nilai, mereka tidak selalu menggunakan kembali hubungan sama sebagai pencarian lain bersama rantai sama. Ini telah berubah, dan sekarang pernyataan F() akan selalu menggunakan hubungan sama sebagai pencarian lain dalam panggilan `filter()` yang sama
- Etiket cetakan `csrf_token` tidak lagi tertutup di sebuah div. Jika anda butuh pengesahan HTML terhadap pra=HTML5 Strict DTD, anda harus menambahkan sebuah div disekitarnya di halaman anda.
- Pustaka cetakan etiket `adminmedia`, yang hanya mengandung etiket etakan diusangkan `{% admin_media_prefix %}`, telah dipindahkan. Berusaha memuat itu dengan `{% load adminmedia %}` akan gagal. Jika cetakan anda masih mengandung baris itu anda harus memindahkannya.
- Karena kelalaian penerapan , itu memungkinkan menggunakan django.contrib.redirects tanpa mengadakan django.contrib.sites. Ini tidak diizinkan lagi. Jika anda sedang menggunakan `django.contrib.redirects`, pastikan `INSTALLED_APPS` mengandung `django.contrib.sites`.
- `BoundField.label_tag` sekarang meloloskan argumen `contents` nya. Untuk menghindari pelolosan HTML, gunakan `django.utils.safestring.mark_safe()` pada argumen sebelum melewatkannya.
- Mengakses pembalikan hubungan one-to-one diambil melalui `select_related()` sekarang memunculkan `DoesNotExist` dari pada mengembalikan `None`.

## Fitur usang di 1.5

### `django.contrib.localflavor`

Aplikasi bantuan localfalvor telah dipisah menjadi paket-paket berbeda. `django.contrib.localflavor` itu sendiri akan dipindahkan di Django 1.6, setelah mempercepat pengusangan.

Paket-paket baru tersedia di GitHub. Tim inti tidak dapat merawat paket-paket ini dalam jangka panjang -- itu terbentang hanya selusin negara pada saat ini; mirip pada terjemahan, perawatan akan diserahkan pada anggota yang tertarik di komunitas.

### `django.contrib.markup`

Modul bantuan markah telah diusangkan dan akan mengikuti jadwal pengusangan dipercepat. Penggunaan langsung dari pustaka markah Python atau pustaka etiket pihak ketiga dipilih untuk Django merawat kegunaan ini di kerangka kerja.

### `AUTH_PROFILE_MODULE`

Dengan perkenalan dari custom user models, tidak lagi butuh untuk mekanisme siap-pakai untuk menyimpan data prodil pengguna.

Anda dapat masih menentukan model profil pengguna yang mempunyai hubungan one-to-one dengan model User - sebenarnya, untuk banyak aplikasi dibutuhkan untuk data terhubung dengan akun User, ini akan menjadi sebuah pola rancangan sesuai untuk diikuti. Bagaimanapun, pengaturan `AUTH_PROFILE_MODULE`, dan metode `django.contrib.auth.models.User.get_profile()` untuk mengakses model profil pengguna, tidak boleh digunakan lagi.

### Mengalirkan perilaku dari `HttpResponse`

Django 1.5 mengusangkan kemampuan mengalirkan tanggapan dengan melewatkan perulangan pada `HttpResponse`. Jika anda bergantung pada perilaku ini, ganti ke `StreamingHttpResponse`. Lihat Secara eksplisit mendukung tanggapan mengalir diatas.

Dalam Django 1.7 dan diatas, perulangan akan memakan segera oleh `HttpResponse`.

### `django.utils.simplejson`

Sejak Django 1.5 menjatuhkan dukungan untuk Python 2.5, kami sekarang dapat bergantung pada modul `json` sedang tersedia di pustaka standar Python, jadi kami telah memindahkan salinan kami sendiri dari `simplejson`. Anda harus sekarang mengimpor `json` dari pada `django.utils.simplejson`.

Sayangnya, perubahan ini mungkin mempunyai pengaruh yang tidak diinginkan, karena ketidaksesuaian diantara versi dari `simplejson` -- lihat bagian backwards-incompatible changes. Jika anda bergantung pada fitur-fitur yang ditambahkan pada `simplejson` setelahnya menjadi `json` Python, anda harus mengimpor `simplejson` dengan tegas.

### `django.utils.encoding.StrAndUnicode`

Minx-in `django.utils.encoding.StrAndUnicode` telah diusangkan. Tentukan metode `__str__` dan berlakukan penghias `python_2_unicode_compatible()` sebagai gantinya.

### `django.utils.itercompat.product`

Fungsi `django.utils.itercompat.product` telah diusangkan. Gunakan `itertools.product()` siap-pakai sebagai gantinya.

### perintah pengelolaan `pembersihan`

Perintah pengelolaan `pembersihan` telah usang dan diganti dengan `clearsessions`.

### Tulisan `daily_cleanup.py`

Tulisan `daily_cleanup.py` tidak terdokumentasi telah diusangkan. Gunakan perintah pengelolaan `clearsessions` sebagai gantinya.

### Argumen kata kunci `depth` di `select_related`

Argumen kata kunci `depth` dalam `select_related()` telah diusangkan. Anda harus menggunakannama bidang sebagai gantinya.