# Dokumentasi Django 5.2.8

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

- Sebuah kerangka untuk menulis tampilan berbasis-kelas.

- Dukungan siap-pakai untuk using Python's logging facilities.

- Dukungan bantuan untuk easy handling of static files.

- Kerangka kerja percobaan Django sekarang mendukung (dan dibekali dengan salinan dari) the unittest2 library.

Wherever possible, new features are introduced in a backwards-compatible manner per our API stability policy policy. As a result of this policy, 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.

See the documentation on class-based generic views for more details. There is also a document to help you convert your function-based generic views to class-based views.

### Pencatatan

Django 1.3 adds framework-level support for Python's `logging` module. This means you can now easily configure and control logging as part of your Django project. A number of logging handlers and logging calls have been added to Django's own code as well -- most notably, the error emails sent on an HTTP 500 server error are now handled as a logging activity. See the documentation on Django's logging interface for more details.

### 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 introduced some major changes to the `unittest` library, adding some extremely useful features. To ensure that every Django project can benefit from these new features, Django ships with a copy of unittest2, a copy of the Python 2.7 `unittest` library, backported for Python 2.4 compatibility.

To access this library, Django provides the `django.utils.unittest` module alias. If you are using Python 2.7, or you have installed `unittest2` locally, Django will map the alias to the installed version of the `unittest` library. Otherwise, Django will use its own bundled version of `unittest2`.

Untuk mengambil keuntungan dari nama lain ini, cukup gunakan:

    from django.utils import unittest

dimanapun anda akan secara riwayat pakai:

    import unittest

If you want to continue to use the base `unittest` library, you can -- you just won't get any of the nice new `unittest2` features.

### 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

If you provide a custom auth backend with `supports_inactive_user` set to `True`, an inactive `User` instance will check the backend for permissions. This is useful for further centralizing the permission handling. See the authentication docs for more details.

### 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 and 1.2 added lots of big ticket items to Django, like multiple-database support, model validation, and a session-based messages framework. However, this focus on big features came at the cost of lots of smaller features.

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.

- Support for HttpOnly cookies.

- `mail_admins()` and `mail_managers()` now support easily attaching HTML content to messages.

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

- A new `render()` shortcut -- an alternative to `django.shortcuts.render_to_response()` providing a `RequestContext` by default.

- Support for combining `F expressions` with `timedelta` values when retrieving or updating database values.

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

If you have an existing project that is using the database session backend, you don't have to do anything to accommodate this change. However, you may get a significant performance boost if you manually add the new index to the session table. The SQL that will add the index can be found by running the `sqlindexes` admin command:

    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.

If you want to restore the old behavior, simply put a `PROFANITIES_LIST` setting in your settings file that includes the words that you want to prohibit (see the commit that implemented this change if you want to see the list of words that was historically prohibited). However, if avoiding profanities is important to you, you would be well advised to seek out a better, less naive approach to the problem.

### 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`.

For example with a `FormSet`:

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

the following code will raise a `ValidationError`:

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

if you need to instantiate an empty `FormSet`, don't pass in the data or use `None`:

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

### Callable di cetakan

Previously, a callable in a template would only be called automatically as part of the variable resolution process if it was retrieved via attribute lookup. This was an inconsistency that could result in confusing and unhelpful behavior:

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

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'`):

- Mirip pada terjemahan ranah `'django'`: Menimpa terjemahan dikirim dengan aplikasi menggunakan pengaturan `LOCALE_PATHS` sekarang memungkinkan untuk ranah ini juga. Terjemahan-terjemahan ini memiliki hak lebih tinggi daripada terjemahan dari paket-paket Python dilewatkan ke tampilan `javascript_catalog()`. Jalur-jalur ditampilkan mempunyai hak lebih tinggi daripada satu yang ditampilkan 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`

The `django.contrib.auth.views.password_reset()` view now accepts a `from_email` parameter, which is passed to the `password_reset_form`’s `save()` method as a keyword argument. If you are using this view with a custom password reset form, then you will need to ensure your form's `save()` method accepts this keyword argument.

## 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`

As a result of the introduction of support for `unittest2`, the features of `django.test.simple.DjangoTestRunner` (including fail-fast and Ctrl-C test termination) have been made redundant. In view of this redundancy, `DjangoTestRunner` has been turned into an empty placeholder class, and will be removed entirely in Django 1.5.

### Dirubah ke `url` dan `ssi`

Most template tags will allow you to pass in either constants or variables as arguments -- for example:

    {% extends "base.html" %}

allows you to specify a base template as a constant, but if you have a context variable `templ` that contains the value `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 marks the start of the process to correct this historical accident. Django 1.3 adds a new template library -- `future` -- that provides alternate implementations of the `url` and `ssi` template tags. This `future` library implement behavior that makes the handling of the first argument consistent with the handling of all other variables. So, an existing template that contains:

    {% url sample %}

should be replaced with:

    {% 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

In previous version the admin app defined login methods in multiple locations and ignored the almost identical implementation in the already used auth app. A side effect of this duplication was the missing adoption of the changes made in r12634 to support a broader set of characters for usernames.

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

- Previously, calling `transform()` would silently do nothing when GDAL wasn't available. Now, a `GEOSException` is properly raised to indicate possible faulty application code. A warning is now raised if `transform()` is called when the SRID of the geometry is less than 0 or `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).

- There are potential strange development- and deployment-time problems like the fact that the `project_dir/locale/` subdir can generate spurious error messages when the project directory is added to the Python path (`manage.py runserver` does this) and then it clashes with the equally named standard library module, this is a typical warning message:

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