Catatan terbitan Django 1.2

Mei 17, 2010.

Selamat datang di Django 1.2!

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

Ikhtisar

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

Ini hanya sorotan; rincian penuh dan daftar lengkap dari fitur-fitur may be found below.

lihat juga

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

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

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

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

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

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

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

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

  • user_passes_test(), login_required(), dan permission_required(), penghias dari django.contrib.auth hanya berlaku pada fungsi dan tidak lagi bekerja pada metode. Ada sebuah perbaikan satu-baris sederhana detailed below.

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

Kesesuaian Python

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

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

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

Apa yang baru di Django 1.2

Mendukung untuk banyak basisdata

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

Validasi model

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

Perbaikan perlindungan CSRF

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

Kerangka pesan

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

Tingkat-obyek perizinan

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

Perizinan untuk pengguna anonim

Jika anda menyediakan backend pembuktian keaslian penyesuaian dengan supports_anonymous_user disetel ke True, AnonymousUser akan memeriksa backend untuk perizinan, sama seperti User telah lakukan. Ini sangan berguna untuk memusatkan penganganan perizinan - aplikasi dapat selalu menugaskan pertanyaan apakah sesuatu diizinkan atau tidak ke backend otorisasi/pembuktian keaslian. Lihat dokumentasi pembuktian keaslian untuk lebih rinci.

Persyaratan santai untuk nama pengguna

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

Backend surel

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

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

Etiket “Smart” if

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

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

Anda dapat sekarang melakukan ini:

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

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

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

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

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

Cetakan penyembunyian

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

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

Pemuat cetakan berdasarkan kelas

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

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

Jika anda telah mengembangkan pemuat cetakan penyesuaian anda kami menyarankan mempertimbangkan menautkan mereka ke penerapan berdasarkan-kelas karena kode untuk kesesuaian kebelakang dengan pemuat berdasarkan-fungsi memulai pengolahan pengusangannya di Django 1.2 dan akan dipindahkan di Django 1.4. Ada sebuah gambaran dari API kelas-kelas pemuat ini harus diterapkan di acuan cetakan API dan anda dapat juga menguji kode sumber dari pemuat yang dibekali dengan Django.

Kunci alami di perlengkapan

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

Kegagalan cepat untuk percobaan

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

BigIntegerField

Model dapat sekarang menggunakan jenis BigIntegerField 64-bit.

Perbaikan lokalisasi

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

readonly_fields di ModelAdmin

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

Penyorotan sintaksis disesuaikan

Anda dapat sekarang menggunakan variabel lingkungan DJANGO_COLORS untuk merubah atau meniadakan warna digunakan oleh django-admin.py untuk menyediakan syntax highlighting.

Umpan perkongsian sebagai tampilan

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

GeoDjango

Fitur baru paling penting dari GeoDjango di 1.2 adalah mendukung untuk banyak basisdata spasial. Sebagai hasilnya, spatial database backends berikut sekarang disertakan:

  • django.contrib.gis.db.backends.postgis
  • django.contrib.gis.db.backends.mysql
  • django.contrib.gis.db.backends.oracle
  • django.contrib.gis.db.backends.spatialite

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

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

Metode berikut GeoQuerySet adalah baru di 1.2:

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

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

Akhirnya, GeoDjango’s documentation sekarang disertakan dengan Django dan tidak lagi ditempatkan terpisah pada geodjango.org.

Bentuk etiket cetakan Now baru menentukan karakter: c dan u

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

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

Perubahan bertentangan kebelakang di 1.2

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

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

Proteksi CSRF

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

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

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

    Dokumentasi dipindahkan

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

  • CsrfViewMiddleware disertakan di MIDDLEWARE_CLASSES secara awalan. Ini merubah perlindungan CSRF secara awalan, sehingga tampilan yang menerima permintaan POST butuh ditulis kembali bekerja dengan middleware. Petunjuk-petunjuk pada bagaimana melakukan ini ditemukan di dokumen CSRF.

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

Metode get_db_prep_*() pada Field

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

class CustomModelField(models.Field):
    # ...
    def db_type(self):
        # ...

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

    def get_db_prep_value(self, value):
        # ...

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

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

class CustomModelField(models.Field):
    # ...

    def db_type(self, connection):
        # ...

    def get_prep_value(self, value):
        # ...

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

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

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

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

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

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

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

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

Etiket cetakan mempertahan keadaan

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

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

Anda mungkin juga butuh memperbaharui cetakan anda jika anda sedang menggantungkan pada penerapan dari etiket cetakan Django bukan menjadi thread safe. Etiket cycle adalah paling disukai untuk dipengaruhi di cara ini, khususnya ketika digunakan di rangkaian dengan etiket include. Pertimbangkan mengikuti fragmen cetakan berikut:

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

dengan subtemplate.html yang membaca:

{% cycle 'even' 'odd' %}

Menggunakan non-thread-safe, pembangun pra-Django 1.2, ini akan mengeluarkan:

even odd even odd ...

Menggunakan pembangun Django 1.2 thread-safe, anda akan mendapatkan sebagai gantinya:

even even even even ...

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

user_passes_test, login_required dan permission_required

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

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

class MyClass(object):

    @login_required
    def my_view(self, request):
        pass

untuk ini:

from django.utils.decorators import method_decorator

class MyClass(object):

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

atau:

from django.utils.decorators import method_decorator

login_required_m = method_decorator(login_required)

class MyClass(object):

    @login_required_m
    def my_view(self, request):
        pass

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

Etiket if berubah

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

LazyObject

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

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

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

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

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

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

__dict__ pada instance model

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

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

Kode keadaan keluar penjalan percobaan

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

ModelForm.is_valid() dan ModelForm.errors

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

BooleanField pada MySQL

Di versi sebelumnya dari Django, BooleanField model dibawah MySQL akan mengemblikan nilainya sebagai baik 1 atau 0, sebagai gantinya dari True atau False; untuk kebanyakan orang ini bukanlah sebuah masalah karena bool adalah sebuah subkelas dari int di Python. Di Django 1.2, bagaimanapun, BooleanField pada MySQL dengan ebnar mengembalikan bool asli. Hanya waktu ini harus pernah menjadi masalah jika anda mengharapkan repr dari sebuah BooleanField untuk mencetak 1 atau 0.

Perubahan pada penafsiran dari max_num di FormSets

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

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

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

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

lihat juga

Penanganan dibantu-JavaScript dari obyek terhubung berderet di admin

email_re

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

Fitur usang di 1.2

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

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

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

lihat juga

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

Menentukan basisdata

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

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

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

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

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

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

Ini mempengaruhi pengaturan berikut:

Pengaturan lama

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

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

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

Backend basisdata postgresql

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

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

Middleware menulis kembali-tanggapan CSRF

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

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

Dokumentasi dipindahkan

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

SMTPConnection

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

from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)

...harus sekarang memanggil get_connection() untuk mencontohkan hubungan surel umum:

from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)

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

from django.core.mail import get_connection
connection = get_connection('django.core.mail.backends.smtp.EmailBackend')
messages = get_notification_email()
connection.send_messages(messages)

Jika panggilan anda untuk membangun sebuah instance dari SMTPConnection membutuhkan argumen tambahan, argumen-argumen itu dapat dilewatkan ke panggilan get_connection():

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

API Pesan Pengguna

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

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

user.message_set.create('a message')

...dengan berikut:

from django.contrib import messages
messages.add_message(request, messages.INFO, 'a message')

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

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

...dengan:

from django.contrib import messages
for message in messages.get_messages(request):
    ...

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

Fungsi pembantu bentuk tanggal

django.utils.translation.get_date_formats() dan django.utils.translation.get_partial_date_formats() telah diusangkan dalam mendukung dari panggilan yang sesuai pada django.utils.formats.get_format(), yang merupakan sadar-lokal ketika USE_L10N disetel ke True, dan kembali ke pengaturan awalan jika setel ke False.

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

from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()

...gunakan:

from django.utils import formats
date_format = formats.get_format('DATE_FORMAT')
datetime_format = formats.get_format('DATETIME_FORMAT')
time_format = formats.get_format('TIME_FORMAT')

Atau, ketika secara langsung membentuk sebuah nilai tanggal:

from django.utils import formats
value_formatted = formats.date_format(value, 'DATETIME_FORMAT')

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

  • DEFAULT_DATE_INPUT_FORMATS
  • DEFAULT_TIME_INPUT_FORMATS
  • DEFAULT_DATETIME_INPUT_FORMATS

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

Pejalan percobaan berdasarkan-fungsi

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

Umpan balik di django.contrib.syndication.feeds

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

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

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

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

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

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

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

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

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

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

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

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

    # ...

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

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

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

Untuk informasi lebih, lihat syndication framework documentation penuh.

ID pesan teknis

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

GeoDjango

Untuk mengizinkan dukungan banyak basisdata, internal basisdata GeoDjango berubah secara mendasar. Perubahan terbesar ketidaksesuaian-kebelakang adalah bahwa modul django.contrib.gis.db.backend telah dinamai kembali menjadi django.contrib.gis.db.backends, dimana sepenuhnya spatial database backends sekarang ada. Bagian berikut menyediakan informasi pada PI paling-terkenal yang terpengaruhi oleh perubahan ini.

SpatialBackend

Sebelum pembuatan dari backend spasial terpisah, obyek django.contrib.gis.db.backend.SpatialBackend disediakan sebagai sebuah abstraksi untuk menginterospeksi pada kemampuan dari basisdata spasial. Semua atribut dan rutin disediakan oleh SpatialBackend sekarang bagian dari atribut ops dari backend basisdata.

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

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

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

Akan perlu dirubah:

from django.db import connection
PostGISAdaptor = connection.ops.Adapter

Model SpatialRefSys dan GeometryColumns.

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

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

Catatan

Karena struktur tabel dari tabel metadata spasial OGC berbeda terhadap basisdata spasial, model SpatialRefSys dan GeometryColumns tidak lagi dapat dikaitkan dengan nama aplikasi gis. Dengan demikian, tidak ada model akan dikembalikan ketika menggunakan metode get_models di contoh berikut:

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

Untuk mendapatkan SpatialRefSys dan GeometryColumns benar untuk basisdata spasial anda gunakan metode disediakan oleh backend spasial:

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

Catatan

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

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

Kode bahasa no

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

Pemuat cetakan berdasarkan fungsi

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

Catatan terbitan Django 1.2.1
Catatan terbitan Django 1.1.4
Back to Top