Catatan terbitan Django 1.3

23 Maret 2011

Selamat datang di Django 1.3!

Hampir setahun dalam membuat, The same applies1.3 termasuk sedikit new features dan cukup dari perbaikan kesalahan dan peningkatan pada fitur-fitur yang ada. Catatan terbitan ini melingkupi fitur-fitur baru di 1.2, dan juga beberapa backwards-incompatible changes anda ingin disadari dari ketika meningkatkan dari Django 1.2 atau versi terlama.

Ikhtisar

Fokus Django 1.3 kebanyakan pada memecahkan lebih kecil, permintaan fitur yang lama berdiri, tetapi tidak mencegah sedikit fitur baru cukup dignifikan dari mendarat, termasuk:

Sedapat mungkin, tentu saja, fitur-fitur baru diperkenalkan di sikap kesesuaian-kebelakang per kebijakan our API stability policy. Sebagai hasil dari kebijakan ini, Django 1.3 begins the deprecation process for some features.

Kesesuaian Python

Terbitan dari The same applies1.2 adalah penting untuk mempunyai pergantian pertama di kebijakan kesesuaian Python Django; sebelum Django 1.2, Django mendukung tiap versi 2.x dari Python mulai 2.3 keatas. Mulai Django 1.2, persyaratan minimal telah dimunculkan pada Python 2.4.

Django 1.3 lanjut mendukung Python 2.4, tetapi akan menjadi rangkaian terbitan Django akhir untuk melakukannya; dimuai dengan Django 1.4, versi Python minimal yang didukung akan menjadi 2.5. Sebuah dokumen menguraikan linimasa penuh kami untuk pengusangan Python 2.x dan berpindah ke Python 3.x akan diterbitkan secepatnya setelah terbitan Django 1.3.

Apa yang baru di Django 1.3

Tampilan berdasarkan-kelas

Django 1.3 menambahkan sebuah keangka kerja yang mengizinkan anda menggunakan kelas sebagai tampilan. Ini berarti anda dapat menyusun tampilan dari kumpulan dari metode yang dapat di subkelaskan dan ditimpa untuk menyesiakan tampilan umum data tanpa harus menulis kode terlalu banyak.

Analog untuk semua tampilan umum berdasarkan-fungsi lama telah disediakam, bersama dengan kelas dasar tampilan umum lengkap yang dapat digunakan sebagai dasar untuk penggunaan kembali aplikasi yang dapat dengan mudah diperpanjang.

Lihat the documentation on class-based generic views untuk lebih rinci. Ada juga sebuah dokumen untuk membantu anda convert your function-based generic views to class-based views.

Pencatatan

Django 1.3 menambahkan dukungan tingkatan-kerangka kerja untuk modul logging Python. Ini berarti anda dapat sekarang dengan mudah mengkonfigurasi dan mengendalikan pencatatan sebagai bagian dari proyek Django anda. Sejumlah penangan pencatatan dan pencatatan panggilan telah ditambahkan juga ke kode sendiri Django -- kebanyakan terutama, surel kesalahan dikirim pada kesalahan peladen HTTP 500 sekarang ditangani sebagai sebuah aktivitas pencatatan. Lihat the documentation on Django's logging interface untuk lebih rinci.

Memperpanjang penanganan berkas tetap

Django 1.3 dibekali dengan aplikasi bantuan baru -- django.contrib.staticfiles -- untuk membantu pengembang manangani berkas-berkas media tetap (gambar, CSS, JavaScript, dll.) yang dibutuhkan untuk membangun sebuah halaman jaringan lengkap.

Di versi sebelummnya, itu adalah tempat umum untuk menempatkan aset tetap di MEDIA_ROOT bersama dengan berkas-berkas diunggah-pengguna, dan melayani mereka kedua di MEDIA_URL. Bagian dari tujuan untuk memperkenalkan aplikasi staticfiles adalah untuk membuatnya lebih mudah menjaga berkas-berkas tetap terpisah dari berkas-berkas terunggah-pengguna. Aset tetap harus sekarang berada di subdirektori static/ dari aplikasi anda atau di direktori aset tetap lain terdaftar di STATICFILES_DIRS, dan akan dilayani pada STATIC_URL.

Lihat reference documentation of the app untuk lebih rinci atau pelajari bagaimana untuk manage static files.

dukungan unittest2

Python 2.7 memperkenalkan beberapa perubahan utama pada pustaka unittest, menambahkan beberapa fitur yang sangat berguna. Untuk memastikan bahwa setiap proyek Django dapat mengambil keuntungan dari fitur-fitur baru ini, Django membekali dengan salinan dari unittest2, sebuah salinan dari pustaka unittest Python 2.7, dihubungkan untuk kesesuaian Python 2.4.

Untuk mengakses pustaka ini, Django menyediakan nama lain modul django.utils.unittest. Jika anda sedang menggunakan Python 2.7, atau anda telah memasang unittest2 secara lokal, Django akan memetakan nama lain ke versi terpasang dari pustaka unittest. Sebaliknya, Django akan menggunakan versi gabungannya sendiri dari unittest2.

Untuk mengambil keuntungan dari nama lain ini, cukup gunakan:

from django.utils import unittest

dimanapun anda akan secara riwayat pakai:

import unittest

Jika anda ingn melanjutkan menggunakan pustaka unittest dasar, anda dapat -- anda tidak hanya akan mendapatkan fitur-fitur bagus unittest2 baru.

Pengelola konteks transaksi

Pengguna dari Python 2.5 dan diatas dapat sekarang menggunakan fungsi pengelolaan transaksi sebagai pengelola konteks. Sebagai contoh:

with transaction.autocommit():
    # ...

Dapat dikonfigurasi hapus-menurun

ForeignKey dan OneToOneField sekarang menerima sebuah argumen on_delete untuk menyesuaikan perilaku ketika obyek diacu dihapus. Sebelumnya, penghapusan selalu menurun; cara lain tersedia sekarang menyertakan setelan null, setel awalan, setel ke tiap tiap nilai, lindungi, atau tidak lakukan apa-apa.

Untuk informasi lebih, lihat dokumentasi on_delete.

Penanda kontekstual dan komentar untuk deretan karakter dapat diterjemahkan

Untuk terjemahan dertan karakter dengan arti yang menyangsingkan, anda sekarang dapat menggunakan fungsi pgettext untuk menentukan konteks dari deretan karakter.

Dan jika anda hanya ingin menambahkan beberapa informasi untuk penterjemah, anda dapat juga menambahkan komentar penterjemah khusus di sumber.

Untuk informasi lebih, lihat Contextual markers dan Komentar untuk penterjemah.

Perbaikan pada etiket cetakan siap-pakai

Sejumlah perbaikan telah dibuat pada etiket cetakan Django siap-pakai:

  • Etiket include sekarang menerima sebuah pilihan with, mengizinkan anda menentukan konteks variabel ke cetakan yang disertakan
  • Etiket include sekarang menerima sebuah pilihan only, mengizinkan anda tidak menyertakan konteks saat ini dari konteks yang disertakan.
  • Etiket with sekarang mengizinkan anda menentukan banyak konteks variabel dalam blok with tunggal.
  • Etiket load sekarang menerima sebuah argumen from, mengizinkan anda memuat etiket tunggal atau penyaring dari sebuah pustaka.

TemplateResponse

Itu dapat terkadang bermanfaat untuk mengizinkan penghias atau middleware untuk merubah sebuah tanggapan setelah itu telah dirancang oleh tampilan. Sebagai contoh, anda ingin merubah cetakan yang digunakan, atau menaruh data tambahan kedalam konteks.

Bagaimanapun, anda tidak dapat (dengan mudah) merubah isi dari dasar HttpResponse setelah itu telah dibangun. Untuk menangani batasan ini, Django 1.3 menambahkan sebuah kelas TemplateResponse baru. Tidak seperti obyek HttpResponse, obyek TemplateResponse menyimpan cetakan dan konteks yang telah disediakan oleh tampilan untuk menghitung tanggapan. Keluaran akhir dari tanggapan tidak dihitung sampai itu dibutuhkan, kemudian di pengolahan tanggapan.

Untul lebih rinci, lihat documentation pada kelas TemplateResponse.

Perubahan menemblok

Django 1.3 melihat perkenalan dari beberapa perbaikan pada infrastruktur penyembunyian Django.

Pertama, Django sekarang mendukung banyak penyimpanan bernama. Di cara yang sama bahwa Django 1.2 diperkenalkan mendukung untuk hubungan abnyak basisdata, Django 1.3 mengizinkan anda menggunakan pengaturan CACHES untuk menentukan banyak hubungan penyimpananbernama.

Yang kedua, versioning, site-wide prefixing dan transformation telah ditambahkan ke API tembolok.

Ketiga, cache key creation telah diperbaharui untuk mengambil deretan karakter permintaan kedalam akun pada permintaan GET.

Akhirnya, sukungan untuk pylibmc telah ditambahkan ke backend tembolok memcached.

Untuk rincian lebih, lihat documentation on caching in Django.

Perizinan untuk pengguna tidak aktif

Jika anda menyediakan backend otentifikasi penyesuaian dengan supports_inactive_user disetel menjadi True, sebuah instance User tidak aktif akan memeriksa backend untuk perizinan. Ini sangat berguna untuk pemusatan penangan perizinan selanjutnya. Lihat authentication docs untuk lebih rinci.

GeoDjango

Deretan percobaan GeoDjango sekarang disertakan ketika running the Django test suite dengan runtests.py ketika menggunakan spatial database backends.

MEDIA_URL dan STATIC_URL harus berakhir di garis miring

Sebelumnya, pengaturan MEDIA_URL hanya membutuhkan buntutan garis miring jika itu mengandung sebuah akhiran diluar nama ranah.

Buntutan garis miring sekarang wajib untuk MEDIA_URL dan pengaturan STATIC_URL selama itu tidak kosong. Ini memastikan ada cara tetap untuk menggabungkan jalur di cetakan.

Pengaturan proyek yang menyediakan salah satu dari kedu apengaturan tanpa buntutan garis miring akan sekarang memunculkan sebuah PendingDeprecationWarning.

Di Django 1.4 kondisi yang sama ini akan memunculkan DeprecationWarning, dan di Django 1.5 akan memunculkan sebuah pengecualian ImproperlyConfigured.

Yang lainnya

Django 1.1 dan 1.2 ditambahkan banyak tiket barang besar pada Django, seperti dukungan banyak-basisdata, pengecekan model, dan kerangka kerja pesan berdasarkan-sesi. Bagaimanapun, fokus ini pada fitur-fitur besar datang pada biaya banyak dari fitur-fitur terkecil.

Untuk mengimbangi ini, fokus dari pengeolahan pengembangan Django 1.3 telah menambahkan banyak dari terkecil, permintaan fitur yang sudah lama berjalan. Ini termasuk:

  • Peningkatan alat-alat untuk mengakses dan merubah obyek Site saat ini di the sites framework.
  • RequestFactory untuk permintaan ejekan di percobaan.
  • Pernyataan percobaan baru -- assertNumQueries() -- membuatnya lebih mudah untuk mencoba aktivitas basisdata terkait dengan tampilan.
  • Mendukung untuk pencarian mencangkup hubungan di list_filter admin.
  • Mendukung untuk kue HTTPOnly.
  • mail_admins() dan mail_managers() sekarang mendukung dengan mudah melampirkan isi HTML pada pesan.
  • EmailMessage sekarang mendukung CC.
  • Surel kesalahan sekarang menyertakan lebih rinci dan berbentuk dari halaman kesalahan peladen pencari kesalahan.
  • simple_tag() sekarang menerima sebuah argumen takes_context, membuatnya lebih mudah untuk menulis etiket cetakan sederhana yang membutuhkan akses ke konteks cetakan.
  • Jalan pintas render() baru -- sebuah jalan lain ke django.shortcuts.render_to_response() menyediakan sebuah RequestContext secara awal.
  • Mendukung untuk F expressions dengan nilai timedelta ketika mengambil atau memperbaharui nilai-nilai basisdata.

Perubahan bertentangan kebelakang di 1.3

Pengesahan CSRF sekarang berlaku pada permintaan AJAX

Sebelum Django 1.2.5, sistem pencegahan CSRF Django membebaskan permintaan AJAX dari pengecekan CSRF, karena security issues dilaporkan ke kami, bagaimanapun, semua permintaan sekarang ditujukan ke pengecekan CSRF. Obrolkan the Django CSRF documentation untuk rincian pada bagimana menangani pengecekan CSRF di permintaan AJAX.

Batasan penyaring di antarmuka admin

Sebelum Django 1.2.5, antarmuka administratif Django mengizinkan menyaring pada bidang model apapun atau hubungan -- tidak hanya itu ditentukan di list_filter -- melalui permintaan pengubahan deretan karakter. Karena masalah keamanan dilaporkan ke kami, bagaimanapun, permintaan argumen pencarian deretan karakter di admin harus untuk bidang atau hubungan ditentukan di list_filter atau date_hierarchy.

Menghapus model tidak menghapus berkas terhubung

Dalam versi paling awal Django, ketika sebuah instance model mengandung sebuah FileField dihapus, FileField mengambil itu pada dirinya sendiri untuk juga menghapus berkas dari penyimpanan backend. Ini membuat pintu untuk beberapa kemungkinan skenario kehilangan-data serius, termasuk transaksi dikembalikan dan bidang-bidang pada model berbeda mengacu berkas sama. Di Django 1.3, ketika sebuah model dihapus metode delete() FileField tidak akan dipanggil. Jika anda butuh membersihkan berkas-berkas tidak bertuan, anda akan butuh menangani nya anda sendiri (sebagai contoh, dengan perintah pengelolaan penyesuaian yang dapat berjalan secara manual atau terjadwal untuk berjalan secara periodeik melalui sebagai contoh cron).

Perilaku membangun awalan PasswordInput

Widget formulir PasswordInput, dimaksudkan untuk digunakan dengan bidang formulir yang mewakili sandi, menerima argumen kata kunci boolean render_value menandakan apakah untuk mengirim datanya kembali ke peramban ketika menampilkan formulir yang diajukan dengan kesalahan. Sebelum pada Django 1.3, argumen ini diawalkan ke True, berarti bahwa sandi diajukan harus dikirim kembali ke peramban sebagai bagian dari formulir. Pengembang yang berharap menambahkan sedikit keamanan tambahan dengan mengecualikan nilai itu dari formulir ditampilkan kembali dapat membuat instance PasswordInput`melewatkan ``render_value=False` .+

Dikarenakan sensitif alamiah dari sandi, bagaimanapun, Django 1.3 mengambil langkah ini secara otomatis; nilai awalan dari render_value sekarang False, dan pengembang yang ingin nilai sandi dikembalikan ke peramban pada pengajuan dengan kesalahan (perilaku sebelumnya) harus secara tegas menunjukkan ini. Sebagai contoh:

class LoginForm(forms.Form):
    username = forms.CharField(max_length=100)
    password = forms.CharField(widget=forms.PasswordInput(render_value=True))

Dapat dibersihkan widget awalan untuk FileField

Django 1.3 sekarang menyertakan sebuah widget formulir ClearableFileInput sebagai tambahan pada FileInput. ClearableFileInput dibangun dengan kotak centang untuk membersihkan nilai bidang (jika bidang mempunyai nilai dan tidak wajib), menyediakan tidak ada arti untuk membersihkan berkas yang ada dari FileField.

ClearableFileInput sekarang widget awalan untuk sebuah FileField, jadi formulir yang ada termasuk FileField tanpa memberikan widget penyesuaian akan butuh dipertanggungjawabkan untuk kemungkinan kotan centang tambahan di formulir keluaran yang dibangun.

Untuk kembali ke pembangunan sebelumnya (tanpa kemampuan membersihkan FileField), gunakan widget FileInput di tempat dari ClearableFileInput. Sebagai contoh, di ModelForm untuk hipotesis model Document dengan sebuah FileField bernama document:

from django import forms
from myapp.models import Document

class DocumentForm(forms.ModelForm):
    class Meta:
        model = Document
        widgets = {'document': forms.FileInput}

Indeks baru pada tabel sesi basisdata

Sebelum pada Django 1.3, tabel basisdata digunakan oleh backend basisdata untuk sessions aplikasi tidak mempunyai indeks pada kolom expire_date. Sebagai hasil, permintaan berdasarkan-tanggal pada tabel sesi -- seperti permintaan yang dibutuhkan untuk membersihkan sesi lama- akan menjadi sangat lambat jika ada banyak sesi.

Jika anda memiliki sebuah proyek yang ada yaitu menggunakan backend sesi basisdata, anda tidak harus melakukan apapun menampung perubahan ini. Bagaimanapun, anda mungkin mendapat dorongan penampilan yang signifikan jika anda secara manual menambahkan indeks baru ke tabel sesi. SQL yang akan menambah indeks dapat ditemukan dengan menjalankan perintah admin sqlindexes:

python manage.py sqlindexes sessions

Tidak ada lagi kata nakal

Django mempunyai riwayat disediakan (dan dipaksakan) daftar dari kata-kata kotor. Aplikasi komentar mempunyai daftar memaksa daftar ini dari kata-kata kotor, mencegah orang dari mengajukan komentar yang mengandung satu dari kata-kata kotor tersebut.

Sayangnya, teknik digunakan untuk menerapkan daftar carut marut ini menyedihkan dibuat-buat, dan cenderung pada Scunthorpe problem. Meningkatkan saringan siap-pakai untuk memperbaiki masalah ini akan membutuhkan usaha yang signifikan, dan sejak bahasa alam mengolah bukan ranah biasa dari kerangka kerja jaringan, kami telah "memperbaiki" masalah dengan membuat daftar dari daftar kosong kata-kata terlarang.

Jika anda ingin menyimpan kembali perilaku lama, cukup taruh pengaturan PROFANITIES_LIST di berkas pengaturan anda yang menyertakan kata anda ingin larang (lihat commit that implemented this change jika anda ingin melihat kata-kata yang riwayatnya dilarang). Bagaimanapun, jika mengindari kata-kata kotor adalah penting bagi anda, anda akan disarankan mencari yang terbaik, sedikit pendekatan yang dibuat-buat pada masalah

Perubahan rasa lokal

Django 1.3 memperkenalkan perubahan bertentangan kebelakang berikut ke rasa lokal:

  • Canada (ca) -- Propinsi "Newfoundland and Labrador" telah mempunyai kode propinsinya diperbaharui menjadi "NL", daripada yang lama "NF". Sebagai tambahan, Yukon Territory telah mempunyai kode propinsinya diralat menjadi "YT", daripada "YK".
  • Indonesia (id) -- Propinsi "Nanggroe Aceh Darussalam (NAD)" telah dipindahkan dari daftar propinsi dalam mendukung dari penyebutan resmi baru "Aceh (ACE)".
  • United States of America (us) -- Daftar dari "states" digunakan oleh USStateField telah diperluas untuk menyertakan kode pos Pasukan Bersenjata. Ini adakah bertentangan kebelakang jika anda bergantung pada USStateField tidak menyertakan mereka.

Perbaharuan FormSet

Di Django 1.3 perilaku pembuatan FormSet adalah merubah sedikit. Secara riwayat kelas tidak membuat perbedaan diantara data tidak sedang dilewatkan dan sedang dilewatkan kamus kosong. Ini adalah tidak konsisten dengan perilaku di bagian lain dari kerangka kerja. Dimulai dengan 1.3 jika anda melewatkan di kamus kosong FormSet akan memunculkan sebuah ValidationError.

Sebagai contoh, dengan sebuah FormSet:

>>> class ArticleForm(Form):
...     title = CharField()
...     pub_date = DateField()
>>> ArticleFormSet = formset_factory(ArticleForm)

kode berikut akan memunculkan sebuah ValidationError:

>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']

Jika anda butuh untuk membuat obyek sebuah FormSet kosong, jangan lewatkan di data atau gunakan None:

>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)

Callable di cetakan

Sebelumnya, callable di cetakan akan hanya dipanggil otomatis sebagai bagian dari pengolah keputusan variabel jika itu telah diambil melalui pencarian atribut. Ini adalah sebuah ketidakkonsistenan yang dapat menghasilkan kebingungan dan perilaku tidak membantu:

>>> Template("{{ user.get_full_name }}").render(Context({'user': user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({'full_name': user.get_full_name}))
u'<bound method User.get_full_name of <...

Itu telah di selesaikan di Django 1.3 - hasil di kedua kasus akan menjadi u'Joe Bloggs'. meskipun perilaku sebelumnya tidak berguna untuk bahasa cetakandirancang untuk perancang jaringan, dan tidak pernah sengaja didukung, itu memungkinkan bahwa beberapa cetakan mungkin rusak oleh perubahan ini.

Penggunaan SQL penyesuaian untuk memuat data inisial di percobaan

Django menyediakan pengkaitan SQL penyesuaian sebagai sebuah cara untuk memasukkan SQL buah-tangan kedalam pengeolahan sinkronisasi basisdata. Satu dari kemungkinan penggunaan untuk penyesuaian SQL ini adalah memasukkan data kedalam basisdata anda. Jika SQL penyesuaian anda mengangund pernyataan INSERT, pemasukan tersebut akan dilakukan setiap kali basisdata anda disinkronkan. Ini termasuk sinkronisasi dari tiap basisdata percobaan yang dibuat ketika anda menjalankan deretan percobaan.

Bagaimanapun, dalam pengolahan dari percobaan Django 1.3, itu ditemukan bahwa fitur ini tidak pernah lengkap bekerja seperti diiklan. Ketika menggunakan backend basisdata yang tidak mendukung transaksi, atau ketika menggunakan TransactionTestCase, data yang telah dimasukkan menggunakan SQL penyesuaian tidak akan nampak selama pengolahan percobaan.

Sayangnya, tidak ada cara untuk memperbaiki masalah ini tanpa memperkenalkan ketidaksesuaian kebelakang. Daripada membiarkan data inisial dimasukkan SQL di keadaan yang tidak menentu, Django sekarang memaksa kebijakan yang data dimasukkan oleh SQL penyesuaian tidak akan nampak selama percobaan.

Perubahan ini hanya mempengaruhi pengolahan percobaan. Anda masih dapat menggunakan SQL penyesuaian untuk memuat data kedalam basisdata produksi anda sebagai bagian dari pengolahan syncdb. Jika anda membutuhkan data untuk ada selama kondisi percobaan, anda harus salah satu memasukkannya menggunakan test fixtures, atau menggunakan metode setUp() dari kasus percobaan anda.

Dirubah prioritas dari memuat terjemahan

Pekerjaan telah diselesaikan untuk memudahkan, merasionalisasi dan algoritma dokumentasi yang sesuai digunakan oleh Django pada saat berjalan untuk membangun terjemahan dari terjemahan berbeda ditemukan di cakram, bernama:

Untuk harfiah dapat diterjemahkan ditemukan di kode Python dan cetakan (ranah gettext 'django')

  • Keutamaan dari terjemahan disertakan dengan aplikasi terdaftar di pengaturan INSTALLED_APPS telah berubah. Untuk menyediakan sebuah perilaku yang tetap dengan bagian lain dari Django yang juga menggunakan pengaturan seperti itu (cetakan, dll) sekarang, ketika membangun terjemahan yang akan dibuat tersedia, aplikasi terdaftar pertama mempunyai hak lebih tinggi daripada satu terdaftar kemudian.
  • Sekarang itu dimungkinkan menimpa terjemahan dibekali dengan aplikasi dengan menggunakan pengaturan LOCALE_PATHS yang terjemahannya sekarang didahulukan lebih tinggi daripada terjemahan dari aplikasi INSTALLED_APPS. Prioritas relatif diantara nilai-nilai terdaftar di pengaturan ini juga telah dirubah jadi jalur terdaftar dahulu mempunyai didahulukan lebih tinggi dari satu didaftar kemudian.
  • Subdirektori locale dari direktori mengandung pengaturan, yang biasanya bertepatan dengan dan dikenal sebagai direktori proyek sedang diusangkan di terbitan ini sebagai sebuah sumber dari terjemahan. (Yang didahulukan dari terjemahan ini adalah pertengahan diantara aplikasi dan terjemahan LOCALE_PATHS). Lihat `corresponding deprecated features section`_dari dokumen ini.

Untuk terjemahan harfiah ditemukan di kode JavaScript (ranah gettext 'djangojs'):

  • Demikian pula pada terjemahan ranah 'django' : utama dari terjemahan dibekali dengan aplikasi dengan menggunakan pengaturan LOCALE_PATHS sekarang memungkinkan untuk ranah ini juga. Terjemahan ini mempunyai hak lebih tinggi daripada terjemahan dari paket Python dilewatkan ke javascript_catalog view. Jalur terdaftar pertama mempunyai hak lebih tinggi daripada sari didaftar kemudian.
  • Terjemahan dibawah subdirektori locale dari direktori proyek belum pernah diperhitungkan untuk terjemahan JavaScript dan tetap di keadaan sama mempertimbangkan pengusangan untuk tempat tersebut.

Pengelolaan transaksi

Ketika menggunakan transaksi dapat dikelola -- yaitu, apapun tetapi suasana autocommit awalan -- adalah terpenting ketika transaksi ditandai sebagai "dirty". Transaksi dirty diperbaiki oleh penghias commit_on_success atau django.middleware.transaction.TransactionMiddleware, dan commit_manually memaksa mereka untuk ditutup secara eksplisit; membersihkan transaksi "get a pass", yang berarti mereka biasanya membatalkan transaksi pada akhir dari permintaan ketika hubungan ditutup.

Sampai Django 1.3, transaksi hanya ditandai dengan kotor ketika Django telah menyadari dari merubah tindakan yang dilakukan di mereka; yaitu baik beberapa model telah disimpan, beberapa perbaharuan dalam jumlah besar atau hapus telah dilakukan, atau pengguna secara eksplisit memanggil transaction.set_dirty(). Di Django 1.3, sebuah transaksi ditandai kotor ketika tiap tindakan basisdata dilakukan.

Sebagai hasil dari perubahan ini, anda tidak lagi butuh menyetel transaksi kotor secara eksplisit ketika anda menjalankan SQL mentah atau menggunakan data-merubah SELECT. Bagaimanapun, anda lakukan perlu secara eksplisit menutup tiap transaksi hanya-baca yang sedang diatur menggunakan commit_manually(). Sebagai contoh:

@transaction.commit_manually
def my_view(request, name):
    obj = get_object_or_404(MyObject, name__iexact=name)
    return render_to_response('template', {'object':obj})

Sebelum Django 1.3, ini akan bekerja tanpa kesalahan. Bagaimanapun, dibawah Django 1.3, ini akan memunculkan sebuah TransactionManagementError karena tindakan membaca yang mengambil instance MyObject meninggalkan transaksi dalam keadaan kotor.

Tidak ada penyetelan kembali sandi untuk pengguna tidak aktif

Sebelum Django 1.3, pengguna tidak aktif dapat meminta surel setel kembali sandi dan menyetel kembali sandi mereka. Di Django 1.3 pengguna tidak aktif akan menerima pesan sama sebagai sebuah akun yang tdak ada.

Tampilan penyetelan ulang sandi sekarang menerima from_email

Tampilan django.contrib.auth.views.password_reset() sekarang menerima sebuah parameter from_email, yang diliewatkan ke metode save() password_reset_form sebagai argumen kata kunci. Jika anda menggunakan tampilan ini dengan penyesuaian formulir setel kembali sandi, kemudian akan akan butuh memastikan metode save() formulir anda menerima argumen kata kunci ini.

Fitur usang di 1.3

Django 1.3 mengusangkan beberapa fitur dari terbitan lebih awal. Fitur-fitur ini masih didukung, tetapi akan bertahapdihapus terhadap siklus terbitan selanjutnya.

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

Di Django 1.4, peringatan ini akan menjadi DeprecationWarning, yang tidak diam. Di Django 1.5 mendukung untuk fitur-fitur ini akan dipindahkan sepenuhnya.

lihat juga

Untuk rincian lebih, lihat dokumentasi Django's release process dan deprecation timeline kami.

dukungan mod_python

Pustaka mod_python belum mempunyai terbitan sejak 2007 atau perbaikan sejak 2008. Badan Apache Foundation memilih untuk memindahkan mod_python dari kumpulan dari proyek aktif di gudang kendali versinya, dan pimpinan pengembangnya telah mengganti semua usahanya menuju lebih ringan, ramping, lebih stabil, dan lebih fleksibel backend mod_wsgi.

Jika anda saat ini menggunakan penangan permintaan mod_python, anda harus menyebarkan kembali proyek Django anda menggunakan penangan permintaan lain. mod_wsgi adalah penangan permintaan dianjurkan oleh proyek Django, tetapi FastCGI juga didukung. Dukungan untuk penyebaran mod_python akan dipindahkan di Django 1.5.

Tampilan umum berdasarkan-fungsi

Sebagai hasil dari perkenalan dari tampilan umum berdasarkan-kelas, tampilan umum berdasarkan fungsi disediakan oleh Django telah diusangkan. Modul-modul berikut dan tampilan mereka kandung telah diusangkan:

  • django.views.generic.create_update
  • django.views.generic.date_based
  • django.views.generic.list_detail
  • django.views.generic.simple

Percobaan klien tanggapan atribut template

Obyek test client returns Response Django diberi keterangan dengan informasi percobaan tambahan. Di Django versi sebelum 1.3, ini menyertakan atribut template mengandung informasi tentang cetakan dibangun dalam membangkitkan tanggapan: baik None, obyek Template tunggal, atau daftar dari obyek Template. Ketidakkonsistenan ini mengembalikan nilai (terkadang daftar, terkadang bukan) membuat atribut sulit bekerja dengannya.

Di Django 1.3 atribut template diusangkan dalam mendukung dari atribut templates baru, yang selalu sebuah daftar, bahkan jika itu hanya mempunyai unsur tunggal atau tidak ada unsur.

DjangoTestRunner

Sebagai hasil dari perkenalan dari mendukung untuk unittest2, fitur-fitur dari django.test.simple.DjangoTestRunner (termasuk cepat-gagal dan pemutusan percobaan Ctrl+C) telah dibuat berlebih. Di tampilan dari berlebihan ini, DjangoTestRunner telah dirubah menjadi sebuah kelas placeholder kosong, dan akan dipindahkan seluruhnya di Django 1.5.

Dirubah ke url dan ssi

Kebanyakan etiket cetakan akan mengizinkan untuk melewati di baik ketetapan atau variabel sebagai argumen -- sebagai contoh:

{% extends "base.html" %}

mengizinkan anda menentukan cetakan dasar sebagai ketetapan, tetapi jika anda mempunyai variabel konteks templ yang mengandung nilai base.html:

{% extends templ %}

juga sah.

Bagaimanapun, karena sebuah kecelakan dari sejarah, url dan ssi adalah berbeda. Etiket ini menggunakan kedua, sintaksis tanpa dikutip, tetapi menafsirkan argumen sebagai ketetapan. Ini berarti itu tidak memungkinkan menggunakan konteks variabel sebagai sasaran dari etiket url dan ssi.

Django 1.3 menandai mulai pengolahan untuk memperbaiki riwayat kecelakaan. Django 1.3 menambahkan pustaka cetakan baru -- future yang menyediakan penerapan lain dari etiket cetakan url dan ssi. Pustaka future ini menerapkan perilaku yang membuat penanganan dari argumen pertama tetap dengan penanganan dari semua variabel lain. Jadi, sebuah cetakan yang ada yang mengandung:

{% url sample %}

harus diganti dengan:

{% load url from future %}
{% url 'sample' %}

Etiket yang menerapkan perilaku lama telah diusangkan, dan di Django 1.5, perilaku lama akan diganti dengan perilaku baru. Untuk memastikan kesesuaian dengan versi selanjutnya dari Django, cetakan yang ada harus dirubah menggunakan pustaka-pustaka future dan sintaksis baru.

Perubahan ke cara masuk dari admin

Di versi aplikasi admin sebelumnya menentukan metode masuk di banyak tempat dan mengabaikan hampir penerapan mirip di aplikasi otentifikasi yang sudah digunakan. Efek samping dari penggandaan ini adalah kehilangan pemakaian dari perubahan dibuat di r12634 untuk mendukung kumpulan lebih luas dari karakter untuk nama pengguna.

Terbitan ini refaktor mekanisme masuk admin untuk menggunakan subkelas dari AuthenticationForm daripada pengesahan formulir manual. Cara tidak terdokumentasi sebelumnya 'django.contrib.admin.sites.AdminSite.display_login_form' telah diusangkan dalam mendukung dari atribut login_form baru.

Perintah pengelolaan reset dan sqlreset

Perintah-perintah tersebut telah diusangkan. Perintah flush dan sqlflush dapat digunakan untuk menghapus apapun. Anda dapat juga menggunakan pernyataan ALTER TABLE atau DROP TABLE secara manual.

GeoDjango

  • TEST_RUNNER berdasarkan-fungsi sebelumnya digunakan untuk menjalankan deretan percobaan GeoDjango, django.contrib.gis.tests.run_gis_tests, akhirnya diusangkan dalam mendukung pejalan percobaan berdasarkan kelas, django.contrib.gis.tests.GeoDjangoTestSuiteRunner.
  • Sebelumnya, memanggil transform() akan secara diam tidak melakukan apapun ketika GDAL tidak tersedia. Sekarang GEOSException secara pantas dimunculkan untuk menunjukkan kemungkinan kegagalan kode aplikasi. Sebuah peringatan sekarang dimunculkan jika transform() dipanggil ketika SRID dari geometri kurang dari 0 atau None

CZBirthNumberField.clean

Sebelumnya metode clean() bidang ini menerima kedua, kelamin, argumen yang mengizinkan pemeriksanaan pengesahan lebih kuat untuk dibuat, bagaimanapun sejak argumen ini dapat tidak pernah sebenarnya dilewatkan dari mesin-mesin formulir Django itu sekarang ditunda pengusangan.

CompatCookie

Sebelumnya, django.http membedah sebuah kelas CompatCookie tidak didokumentasikan, yang merupakan pembungkus perbaikan kesalahan disekitar pustaka standar SimpleCookie. Ketika perbaikan dipindahkan ke hulu, ini sekarang diusangkan - anda harus menggunakan from django.http import SimpleCookie sebagai gantinya.

Memuat penterjemahan tingkatan-proyek

Terbitan dari Django memulai pengolahan pengusangan untuk penyertaan dari terjemahan ditempatkan dibawah disebut jalur proyek di pengolahan membangun terjemahan dilakukan pada saat runtime. Pengaturan LOCALE_PATHS dapat digunakan untuk tugas yang sama dengan menambahkan jalur sistem berkas pada direktori locale mengandung terjemahan tingkatan-proyek pada nilai dari pengaturan itu.

Alasan untuk keputusan ini:

  • jalur proyek selalu konsep ditentukan longgar (sebenarnya, direktori digunakan untuk menempatkan tingkat-proyek terjemahan adalah direktori mengandung pengaturan modul) dan telah ada pergantian di bagian lain dari kerangka kerja untuk menghentikan menggunakan itu sebagai sebuah acuan untuk tempat dari aset pada waktu berjalan.

  • Penemuan dari subdirektori locale cenderung gagal ketika menyebarkan skenario adalah lebih rumit daripada satu yang dasar. sebagai contoh dia gagal ketika modul pengaturan adalah sebuah direktori (tiket #10765).

  • Terdapat kemungkinan pengembangan aneh- dan penyebaran- masalah waktu seperti fakta bahwa subdirektori project_dir/locale/ daapt membangkitkan pesan-pesan kesalahan tiruan ketika direktori proyek ditambahkan ke jalur Python (manage.py runserver melakukan ini) dan kemudian itu bentrok dengan modul pustaka standar dinamai sama, ini adalah pesan kesalahan khas:

    /usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
import locale, copy, os, re, struct, sys

  • Tempat ini tidak disertakan di pengeolahan membangun terjemahan untuk harfiah JavaScript. Pengusangan ini memindahkan ketidakkonsistenan itu.

PermWrapper dipindah ke django.contrib.auth.context_processors

Di Django 1.2, kami mulai mengolah dari merubah tempat dari pengolah konteks auth dari django.core.context_processors menjadi django.contrib.auth.context_processors. Bagaimanapun, PermWrapper``mendukung kelas adalah kesalahan dihilangkan dari perpindahan itu. Di Django 1.3, kelas ``PermWrapper juga dipindahkan ke django.contrib.auth.context_processors, bersama dengan kelas pendukung PermLookupDict . Kelas-kelas baru secara kegunaan mirip pada versi lama mereka; hanya tempat modul yang berubah.

Perpindahan XMLField

Ketika Django pertama kali diterbitkan, Django menyertakan sebuah XMLField yang melakukan pengecekan XML otomatis untuk tiap bidang masukan. Bagaimanapun, fungsi pengecekan ini belum dilakukan sejak perkenalan dari newforms, sebelum pada terbitan 1.0. Sebagai hasil, XMLField sebagai TextField.

Untuk alasan ini, Django 1.3 mempunyai jalur-cepat pengusangan dari XMLField -- sebagai ganti dua-terbitan pengusangan, XMLField akan dipindahkan seluruhnya di Django 1.4.

Itu sangat mudah memperbaharui kode anda untuk menampung perubahan ini -- cukup ganti semua penggunaan dari XMLField dengan``TextField``, dan pindahkan argumen kata kunci schema_path (jika itu ditentukan).

Catatan terbitan Django 1.3.1
Catatan terbitan Django 1.2.7
Back to Top