Catatan terbitan Django 1.1

29 Juli 2009

Selamat datang di Django 1.1!

Django 1.1 menyertakan sejumlah dari new features bagus, banyak perbaikan kesalahan, dan jalur peningkatan mudah dari Django 1.0.

Perubahan bertentangan kebelakang di 1.1

Django mempunyai sebuah kebijakan API stability. Ini berarti bahwa, secara umum, kode anda kembangkan terhadap Django 1.0 harus lanjut bekerja terhadap tanpa perubahan 1.1. Bagaimanapun, kami melakukan terkadang membuat perubahan bertentangan kebelakang jika mereka butuh untuk menyelesaikan kesalahan, dan ada bantuan dari perubahan (kecil) seperti itu diantara Django 1.0 dan Django 1.1.

Sebelum meningkatkan ke Django 1.1 anda harus memeriksa kembali bahwa perubahan berikut tidak berdampak anda, dan tingkatkan kode anda jika mereka lakukan.

Perubahan pada batasan nama

Django 1.1 merubah cara yang digunakan untuk membangkitkan nama batasan basisdata sehingga nama selaras tanpa memperhatikan ukuran kata mesin. Perubahan ini bertentangan kebelakang untuk beberapa pengguna.

Jika anda sedang menggunakan serambi32-bit, anda diluar hubungan; anda akan mengamati tidak ada perbedaan sebagai hasil dari perubahan ini.

Bagaimanapun, pengguna pada serambi 64-bit mungkin mengalami beberapa masalah menggunakan perintah pengelolaan reset. Sebelum ke perubahan ini, serambi 64-bit akan membangkitkan 64-bit, perpendekan 16 karakter di nama batasan; sebagai contoh:

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...

Mengikuti perubahan ini, semua serambi, tanpa memperhatikan ukuran kata, akan membangkitkan 32-bit, perpendekan 8 karakter di nama pembatasan; sebagai contoh:

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...

Sebagai hasil dari perubahan ini, anda tidak akan dapat menggunakan perintah pengelolaan reset pada setiap tabel dibuat oleh mesin 64-bit. Ini karena nama dibangkitkan baru tidak akan cocok secara riwayat nama dibangkitkan; sebagai hasilnya, SQL dibangun oleh perintah pengaturan kembali akan tidak sah.

Jika anda butuh menyetek kembali sebuah aplikasi yang telah dibuat dengan batasan 64-bit, anda akan butuh secara manual menjatuhkan batasan lama sebelum meminta reset.

Kasus percobaan sekarang berjalan di transaksi.

Django 1.1 menjalankan percobaan didalam transaksi, mengizinkan penampilan percobaan terbaik (lihat test performance improvements untuk rincian).

Perubahan ini sedikit bertentangan kebelakang jika percobaan yang ada butuh mencoba perilaku transaksional, jika mereka bergantung pada prasangka tidak sah tentang lingkungan percobaan, atau jika mereka membutuhkan sebuah urutan kasus percobaan khusus.

Untuk kasus-kasus ini, TransactionTestCase dapat digunakan sebagai gantinya. Ini hanya perbaikan cepat untuk berkeliling-keliling kesalahan kasus percobaan terungkap oleh pendekatan rollback baru; di percobaan jangka panjang harus ditulis kembali untuk memperbaiki percobaan kasus.

Pindahkan middleware SetRemoteAddrFromForwardedFor

Untuk kenyamanan, Django 1.0 menyertakan sebuah kelas middleware pilihan – django.middleware.http.SetRemoteAddrFromForwardedFor – yang memperbaharui nilai dari REMOTE_ADDR berdasarkan pada kepala HTTP X-Forwarded-For umumnya disetel oleh beberapa konfigurasi proxy.

Itu telah ditunjukkan bahwa mekanisme ini tidak dapat dibuat cukup handal untuk penggunaan tujuan tertentu, dan bahwa (meskipun dokumentasi ke kebalikan) penyertaannya di Django mungkin membawa pengembang aplikasi menganggap bahwa nilai dari REMOTE_ADDR adalah “safe” atau di beberapa jalan dapat dihandalkan sebagai sumber otentifikasi.

Selagi tidak secara langsung masalah keamanan, kami telah memutuskan untuk memindahkan middleware ini dengan terbitan Django 1.1. Itu telah diganti dengan kelas yang tidak melakukan apapun selaiin menampilkan DeprecationWarning.

Jika anda telah bergantung pada middleware ini, jalur peningkatan termudah adalah:

• Uji the code as it existed before it was removed.

• Periksa bahwa itu bekerja dengan benar dengan proxy hulu anda, merubahnya untuk mendukung proxy tertentu anda (jika dibutuhkan).

• Memperkenalkan versi dirubah anda dari SetRemoteAddrFromForwardedFor sebagai potongan dari middleware di proyek anda sendiri.

Nama dari berkas terunggah tersedia kemudian

Di Django 1.0, berkas-berkas terunggah dan disimpan dalam sebuah FileField model disimpan ke cakram sebelum model disimpan ke basisdata. Ini berarti bahwa nama berkas sebenarnya diberikan ke berkas telah tersedia sebelum disimpan. Sebagai contoh, itu telah tersedia dalam pengangan sinyal pra-simpan model.

Di Django 1.1 berkas disimpan sebagai bagian dari menyimpan model di basisdata, jadi nama berkas sebenarnya digunakan pada cakram tidak dapat bergantung sampai sesudah model telah disimpan.

Perubahan pada bagaimana model formset disimpan

Dalam Django 1.1, BaseModelFormSet sekarang memanggil ModelForm.save().

Ini adalah bertentangan-kebelakang jika anda sedang merubah self.initial dalam model __init__ formset, atau jika anda bergantung pada atribut internal _total_form_count atau _initial_form_count dari BaseFormSet. Atribut tersebut sekarang adalah metode umum.

Diperbaiki perilaku pelolosan saringan join

Penyaring join tidak lagi meloloskan nilai harfiah yang dilewatkan untuk penghubung.

Bertentangan kebelakang ini untuk keadaan khusus dari deretan karakter harfiah mengandung satu dari lima karakter HTML khusus. Jadi, jika anda sedang menulis {{ foo|join:"&" }}, anda sekarang harus menulis {{ foo|join:"&" }}.

Perilaku sebelumnya adalah sebuah kesalahan dan kebalikan ke apa yang telah didokumentasikan dan diharapkan.

Pengalihan tetap dan tampilan umum redirect_to()

Django 1.1 menambahkan argumen permanent ke tampilan django.views.generic.simple.redirect_to(). Ini secara teknis bertentangan kebelakang jika anda menggunakan tampilan redirect_to dengan kunci bentuk-deretan karakter disebut ‘permanent’, yang sangat tidak mungkin.

Fitur usang di 1.1

Satu fitur telah ditandai sebagai usang di Django 1.1:

• Anda jangan lagi menggunakan AdminSite.root() untuk mendaftar tampilan admin itu. Yaitu, jika URLconf anda mengandung baris:

  (r'^admin/(.*)', admin.site.root),
  

  Anda harus merubahnya untuk membaca:

  (r'^admin/', include(admin.site.urls)),
  

Anda harus mulai memindahkan penggunaan fitur ini dari kode anda segera.

AdminSite.root akan menimbulkan PendingDeprecationWarning jika digunakan di Django 1.1. Peringatan ini disembunyikan secara awal. Di Django 1.2, peringatan ini akan ditingkatkan ke DeprecationWarning, yang akan ditampilkan mencolok. Django 1.3 akan memindahkan AdminSite.root() sepenuhnya.

Untuk rincian lebih pada kebijakan dan strategi pengusangan kami, lihat Pengolahan terbitan Django.

Apa yang baru di Django 1.1

Cukup sedikit: sejak Django 1.0, kami telah membuat 1,290 kode perbaikan, memperbaiki 1,206 kesalahan, dan menambahkan kurang lebih 10,000 baris dokumentasi.

Fitur baru utama di Django 1.1 adalah:

Perbaikan ORM

Dua peningkatan utama telah ditambahkan pada object-relational mapper (ORM) Django: mengumpulkan dukungan, dan pernyatana permintaan.

Pengumpulan dukungan

Sekarang memungkinkan menjalankan permintaan kumpulan SQL (yaitu COUNT(), MAX(), MIN(), dll.) dari dalam ORM Django. Anda dapat memilih ke antara mengembalikan hasil dari pengumpulan secara langsung, atau lainnya memberikan keterangan pbjek di QuerySet dengan hasil dari pengumpulan permintaan.

Fitur ini tersedia sebagai metode aggregate() dan annotate() baru, dan melingkupi rincian di the ORM aggregation documentation.

Ekspresi permintaan

Permintaan sekarang dapat merujuk pada bidang lain pada permintaan dan dapat melintasi hubungan untuk mengacu ke bidang pada model terkait. Ini diterapkan dalam obyek F baru; untuk rincian penuh, termasuk contoh, rundingkan F expressions documentation.

Perbaikan model

Sejumlah fitur telah ditambahkan ke lapisan model Django:

Model “Unmanaged”

Anda sekarang dapat mengendalikan apakah atau tidak Django mengelola siklus-hidup dari tabel-tabel basisdata untuk model menggunakan pilihan model managed. Ini awal pada True, berarti bahwa Django akan membuat tabel-tabel basisdata sesuai di syncdb dan memindahkan mereka sebagai bagian dari perintah reset. Yaitu, Django mengelola siklus hidup tabel-tabel basisdata.

Jika anda menyetel ini ke False, bagaimanapun, tidak ada pembautan atau penghapusan tabel basisdata akan otomatis dilakukan untuk model ini. Ini berguna jika model mewakili sebuah tabel atau tampilan basisdata yang ada yang telah dibuat oleh beberapa cara lain.

Untuk lebih rinci, lihat dokumentasi untuk pilihan managed.

Model proxy

Anda sekarang dapat membuat subkelas proxy models: dari model yang ada yang hanya menambahkan tingkat-Python (daripada tingkat-basisdata) dan tidak diwakili oleh tabel baru. yaitu, model baru adalah sebuah proxy untuk beberapa model pokok, yang menyimpan semua data sungguhan.

Semua rincian dapat ditemukan di dokumentasi model proxy. Fitur ini mirip pada permukaan model tidak dikendalikan, jadi dokumentasi punya penjelasan dari bagaimana model proxy berbeda dari models tidak dikendalikan.

Bidang ditangguhkan

Di beberapa keadaan rumit, model anda mungkin mengandung bidang yang dapat mengandung banyak data (sebagai contoh, bidang teks besar), atau membutuhkan pengolahan mahal untuk merubah mereka menjadi obyek Python. Jika anda mengetahui anda tidak butuh bidang khusus itu, anda sekarang dapat memberitahu Django tidak mengambil mereka dari basisdata.

Anda akan melakukan ini dengan metode queryset defer() dan only().

Mencoba perbaikan

Sedikit perbaikan penting telah dibuat pada testing framework.

Pengujian perbaikan penampilan

Perobaan ditulis menggunakan testing framework Django sekarang berjalan lebih cepat secara dramatis (sebanyak 10 kali lebih cepat di banyak kasus).

Ini telah diselesaikan melalui pengenalan dari percobaan berdasar transaksi: ketika menggunakan django.test.TestCase, percobaan anda akan berjalan sekarang di transaksi yang digulung kembali ketika selesai, daripada membilas dan mengumpulkan kembali basisdata. Hasil ini dalam percepatan besar untuk kebanyakan jenis dari satuan percobaan. Lihat dokumentasi untuk TestCase dan TransactionTestCase untuk gambaran penuh, dan beberapa catatan penting pada dukungan basisdata.

Pengujian perbaikan klien

Beberapa kecil – tetapi sangat berguna – perbaikan telah dibuat pada klien percobaan:

• Percobaan Client sekarang dapat otomatis mengikuti pengalihan dengan argumen follow pada Client.get() and Client.post(). Ini membuat tampilan percobaan yang menerbitkan pengalihan lebih sederhana.

• Sekarang lebih mudah mendapatkan cetakan konteks di tanggapan mengembalikan percobaan klien: anda akan cukup mengakses konteks sebagai request.context[key]. Cara lama, yang memperlakukan request.context sebagai dafar konteks, satu untuk setiap cetakan dibangun di rantai warisan, masih tersedia jika anda membutuhkannya.

Fitur admin baru

Django 1.1 menambahkan beberapa fitur baru yang bagus pada antarmuka admin Django:

Bidang dapat dirubah pada daftar perubahan

Anda sekarang dapat membuat bidang disunting pada tampilan daftar admin melalui pilihan admin list_editable baru. Bidang-bidang ini akan menampilkan widget formulir pada daftar halaman, dan dpat disunting dan disimpan dalam jumlah besar.

Admin “actions”

Anda sekarang dapat menentukan admin actions yang dapat melakukan beberapa tindakan pada sekelompok model dalam jumlah besar. Pengguna akan dapat memilih obyek pada perubahan daftar halaman dan kemudian memberlakukan tindakan dalam jumlah besar ini pada semua obyek terpilih.

Django dibekali dengan satu tindakan admin pra penentuan untuk menghapus sebuah kelompok dari obyek di sekali kejadian.

Pengolahan tampilan bersyarat

Django sekarang mempunyai lebih baik dukungan untuk conditional view processing menggunakan standar kepala HTTP ETag dan Last-Modified. Ini berarti anda sekarang dapat dengan mudah mengolah tampilan arus-pendek dengan mencoba persyaratan lebih-murah. Untuk banyak tampilan ini dapat membawa ke perbaikan berat dalam kecepatan dan pengurangan di pita lebar.

Namespace URL

Django 1.1 memperbaiki named URL patterns dengan perkenalan dari URL “namespaces.”

Pendeknya, fitur ini mengizinkan kelompok sama dari URL, dari aplikasi sama, untuk disertakan di Django URLConf beberapa kali, dengan beragam (dan kemungkinan bersarang) awalan bernama yang akan digunakan ketika melakukan membalikkan keputusan. Dengan kata lain, aplikasi digunakan kembali seperti antarmuka admin Django mungkin mendaftar beberapa kali tanpa pertentangan URL.

Untuk rincian penuh, lihat the documentation on defining URL namespaces.

GeoDjango

Di Django 1.1, GeoDjango (yaitu django.contrib.gis) mempunyai beberapa fitur baru:

• Dukungan untuk SpatiaLite – basisdata spasial untuk SQLite – sebagai backend spasial.

• Pengumpulan geografis pernyataan (Collect, Extent, MakeLine, Union) dan F.

• Metode GeoQuerySet baru: collect, geojson, dan snap_to_grid.

• Daftar antarmuka metode baru dari obyek GEOSGeometry.

Untuk lebih rinci, lihat dokumentasi GeoDjango.

Perbaikan lain

Fitur baru dan perubahan diperkenalkan sejak Django 1.0 termasuk:

• CSRF protection middleware telah dipisah menjadi dua kelas – CsrfViewMiddleware memeriksa permintaan datang, dan CsrfResponseMiddleware mengolah tanggapan keluar. Paduan kelas CsrfMiddleware (yang melakukan keduanya) tetap untuk kesesuaian-kebelakang, tetapi menggunakan kelas-kelas terpisah sekarang dianjurkan agar mengizinkan kendali jaringan-halus dari ketika dan dimana pengolahan CSRF mengambil tempat.+

• reverse()` dan kode yang menggunakannya (sebagai contoh, etiket cetakan {% url %}) sekarang bekerja dengan URL di situs administratif Django, asalkan URL admin disetel melalui include(admin.site.urls) (mengirim permintaan admin ke tampilan admin.site.root masih bekerja, tetapi URL di admin tidak akan “reversible” ketika mengkonfigurasi cara ini).

• Fungsi include() di modul Django URLconf sekarang dapat menerima urutan dari pola URL (dibangkitkan oleh patterns()) sebagai tambahan ke nama modul.

• Contoh dari formulir Django (lihat the forms overview) sekarang mempunyai dua metode tambahan, hidden_fields() dan visible_fields(), yang mengembalikan daftar dari tersembunyi – yaitu, <input type="hidden"> – dan bidang-bidang nampak pada formulir, masing-masing.

• Tampilan umum redirect_to sekarang menerima sebuah argumen kata kunci tambahan permanent. Jika permanent adalah True, tampilan akan mengeluarkan pengalihan tetap HTTP (kode keadaan 301). Jika False, tampilan akan mengeluarkan pengalihan sementara HTTP (kode keadaan 302).

• Jenis pencarian basisdata baru – week_day – telah ditambahkan untuk DateField dan DateTimeField. Jenis ini dari pencarian menerima angka diantara 1 (Minggu) dan 7 (Sabtu), dan mengembalikan sebuah obyek dimana nilai bidang cocok hari itu dari minggu. Lihat the full list of lookup types untuk rincian.

• Etiket {% for %} di bahasa cetakan Django sekarang menerima sebuah pilihan klausa {% empty %}, untuk ditampilkan ketika {% for %} diminta berputar terhadap urutan kosong. Lihat the list of built-in template tags untuk contoh dari ini.

• Perintah pengelolaan dumpdata sekarang menerima nama model tersendiri sebagai argumen, mengizinkan anda untuk mengekspor data cukup dari model tertentu.

• Ada cetakan penyaring safeseq baru yang bekerja seperti safe untuk daftar, menandai setiap barang di daftar sebagai safe.

• Cache backends sekarang mendukung perintah incr() dan decr() untuk menaikkan dan menurunkan nilai dari kunci tembolok. Pada backend tembolok yang mendukung menaik/menurun kecil – paling terutama, memcache backend – tindakan ini akan menjadi kecil, dan sangat cepat.

• Django sekarang dapat easily delegate authentication to the Web server melalui backend pengecekan baru yang mendukung standar variabel lingkungan REMOTE_USER digunakan untuk tujuan ini.

• Ada fungsi django.shortcuts.redirect() baru yang membuatnya lebih mudah mengeluarkan pengalihan yang diberikan sebuah obyek, nama tampilan, atau URL.

• Backend postgresql_psycopg2 sekarang mendukung native PostgreSQL autocommit. Ini merupakan lanjutan, fitur khusus-PostgreSQL, yang dapat membuat aplikasi tertentu membaca-berat menjadi lebih cepat.

Apa Selanjutnya?

Kami akan mengambil istirahat pendek, dan kemudian kerja pada Django 1.2 akan dimulai – tidak ada istirahat untuk lelah! Jika anda suka membantu, obrolan dari pengembangan Django, termasuk kemajuan terhadap terbitan 1.2, mengambil tempat harian pada daftar penyuratan django-developers dan di saluran IRC #django-dev pada irc.freenode.net. Jangan ragu untuk bergabung di obrolan.

Dokumentasi daring Django juga menyertakan petunjuk pada bagaimana membantu Django:

• How to contribute to Django

Bantuan pada tiap tingkatan – mengembangkan kode, menulis dokumentasi atau hanya mendahulukan tiket dan membantu untuk mencoba perbaikan kesalahan yang diajukan – selalu disambut dan dihargai.

Dan itulah cara itu.