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:

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.

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

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).

  • Perintah pengelolaan dumpdata mengeluarkan satu baris pada satu waktu, mencegah kesalahan kehabisan-memori ketika mengeluarkan dataset besar.

  • 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:

  • Selagi API simplejson didokumentasikan sebagai selalu mengembalikan deretan karakter unicode, penerapan pilihan C dapat mengembalikan deretan karakter byte. Ini telah diperbaiki di Python 2.7.
  • simplejson.JSONEncoder mendapatkan sebuah argumen kata kunci namedtuple_as_object di versi 2.2.

Informasi lebih pada ketidaksesuaian ini tersedia di 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

Jika anda telah menulis custom password hasher, metode encode(), verify() atau safe_summary() anda harus menerima parameter Unicode (password, salt atau encoded). Jika tiap dari cara campuran butuh byte deretan karakter, anda dapat menggunakan kegunaan force_bytes() untuk menyandi deretan karakter.

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:

  • Pertama, semua unittest (termasuk unittest.TestCase, SimpleTestCase, TestCase dan TransactionTestCase) berjalan dengan tanpa urutan tertentu menjamin atau ditegakkan terhadap mereka.
  • 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
  • Penyaring cetakan slugify sekarang tersedia sebagai sebuah standar fungsi python pada django.utils.text.slugify(). Demikian pula, remove_tags tersedia pada 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.

Catatan terbitan Django 1.5.1
Catatan terbitan Django 1.4.22
Back to Top