---
title: "Catatan terbitan Django 1.1"
version: 6.0
locale: id
source: https://docs.djangoproject.com/id/6.0/releases/1.1/
canonical: https://djangodocs.dev/id/6.0/releases/1.1/
---
# Catatan terbitan Django 1.1

29 Juli 2009

Selamat datang di Django 1.1!

Django 1.1 menyertakan sejumlah dari [new features](#whats-new-1-1) bagus, banyak perbaikan kesalahan, dan jalur peningkatan mudah dari Django 1.0.

## Perubahan bertentangan kebelakang di 1.1

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

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

### Perubahan pada batasan nama

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

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

However, **users on 64-bit platforms may experience some problems** using the
`reset` management command. Prior to this change, 64-bit platforms
would generate a 64-bit, 16 character digest in the constraint name; for
example:

```sql
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...
```

Following this change, all platforms, regardless of word size, will generate a
32-bit, 8 character digest in the constraint name; for example:

```sql
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
```

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

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

### Kasus percobaan sekarang berjalan di transaksi.

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

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

Untuk kasus-kasus ini, [`TransactionTestCase`](/id/6.0/topics/testing/tools/#django.test.TransactionTestCase) dapat digunakan sebagai gantinya. Ini hanya perbaikan cepat untuk berkeliling-keliling kesalahan kasus percobaan terungkap oleh pendekatan rollback baru; di percobaan jangka panjang harus ditulis kembali untuk memperbaiki percobaan kasus.

### Pindahkan middleware `SetRemoteAddrFromForwardedFor`

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

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

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

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

- Uji [the code as it existed before it was removed](https://github.com/django/django/blob/91f18400cc0fb37659e2dbaab5484ff2081f1f30/django/middleware/http.py#L33).
- Periksa bahwa itu bekerja dengan benar dengan proxy hulu anda, merubahnya untuk mendukung proxy tertentu anda (jika dibutuhkan).
- Memperkenalkan versi dirubah anda dari `SetRemoteAddrFromForwardedFor` sebagai potongan dari middleware di proyek anda sendiri.

### Nama dari berkas terunggah tersedia kemudian

Di Django 1.0, berkas-berkas terunggah dan disimpan dalam sebuah [`FileField`](/id/6.0/ref/models/fields/#django.db.models.FileField) model disimpan ke cakram sebelum model disimpan ke basisdata. Ini berarti bahwa nama berkas sebenarnya diberikan ke berkas telah tersedia sebelum disimpan. Sebagai contoh, itu telah tersedia dalam pengangan sinyal pra-simpan model.

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

### Perubahan pada bagaimana model formset disimpan

Dalam Django 1.1, [`BaseModelFormSet`](/id/6.0/topics/forms/modelforms/#django.forms.models.BaseModelFormSet) sekarang memanggil `ModelForm.save()`.

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

### Diperbaiki perilaku pelolosan saringan `join`

Penyaring [`join`](/id/6.0/ref/templates/builtins/#std-templatefilter-join) tidak lagi meloloskan nilai harfiah yang dilewatkan untuk penghubung.

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

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

### Pengalihan tetap dan tampilan umum `redirect_to()`

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

## Fitur usang di 1.1

Satu fitur telah ditandai sebagai usang di Django 1.1:

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

  ```
  (r"^admin/(.*)", admin.site.root),
  ```

  Anda harus merubahnya untuk membaca:

  ```
  (r"^admin/", include(admin.site.urls)),
  ```

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

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

Untuk rincian lebih pada kebijakan dan strategi pengusangan kami, lihat [Pengolahan terbitan Django](/id/6.0/internals/release-process/).

## Apa yang baru di Django 1.1

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

Fitur baru utama di Django 1.1 adalah:

### Perbaikan ORM

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

#### Pengumpulan dukungan

Sekarang memungkinkan menjalankan permintaan kumpulan SQL (yaitu `COUNT()`, `MAX()`, `MIN()`, dll.) dari dalam ORM Django. Anda dapat memilih ke antara mengembalikan hasil dari pengumpulan secara langsung, atau lainnya memberikan keterangan pbjek di [`QuerySet`](/id/6.0/ref/models/querysets/#django.db.models.query.QuerySet) dengan hasil dari pengumpulan permintaan.

Fitur ini tersedia sebagai metode [`aggregate()`](/id/6.0/ref/models/querysets/#django.db.models.query.QuerySet.aggregate) dan [`annotate()`](/id/6.0/ref/models/querysets/#django.db.models.query.QuerySet.annotate) baru, dan melingkupi rincian di [the ORM aggregation documentation](/id/6.0/topics/db/aggregation/).

#### Ungkapan permintaan

Permintaan sekarang dapat mengacu pada bidang lain pada permintaan dan dapat melintasi hubungan untuk mengacu ke bidang-bidang pada model-model terkait. Ini diterapkan dalam obyek [`F`](/id/6.0/ref/models/expressions/#django.db.models.F) batu; untuk rincian lengkap, termasuk contoh-contoh, periksa [`F expressions documentation`](/id/6.0/ref/models/expressions/#django.db.models.F).

### Perbaikan model

Sejumlah fitur telah ditambahkan ke lapisan model Django:

#### Model "Unmanaged"

Anda sekarang dapat mengendalikan apakah atau tidak Django mengelola siklus-hidup dari tabel-tabel basisdata untuk model menggunakan pilihan model [`managed`](/id/6.0/ref/models/options/#django.db.models.Options.managed). Ini awal pada `True`, berarti bahwa Django akan membuat tabel-tabel basisdata sesuai di `syncdb` dan memindahkan mereka sebagai bagian dari perintah `reset`. Yaitu, Django *mengelola* siklus hidup tabel-tabel basisdata.

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

Untuk lebih rinci, lihat dokumentasi untuk pilihan [`managed`](/id/6.0/ref/models/options/#django.db.models.Options.managed).

#### Model proxy

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

Semua rincian dapat ditemukan di [dokumentasi model proxy](/id/6.0/topics/db/models/#proxy-models). Fitur ini mirip pada permukaan model tidak dikendalikan, jadi dokumentasi punya penjelasan dari [bagaimana model proxy berbeda dari models tidak dikendalikan](/id/6.0/topics/db/models/#proxy-vs-unmanaged-models).

#### Bidang ditangguhkan

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

Anda akan melakukan ini dengan metode queryset [`defer()`](/id/6.0/ref/models/querysets/#django.db.models.query.QuerySet.defer) dan [`only()`](/id/6.0/ref/models/querysets/#django.db.models.query.QuerySet.only).

### Mencoba perbaikan

Sedikit perbaikan penting telah dibuat pada [testing framework](/id/6.0/topics/testing/).

#### Pengujian perbaikan penampilan

Perobaan ditulis menggunakan [testing framework](/id/6.0/topics/testing/) Django sekarang berjalan lebih cepat secara dramatis (sebanyak 10 kali lebih cepat di banyak kasus).

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

### Pengujian perbaikan klien

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

- Percobaan [`Client`](/id/6.0/topics/testing/tools/#django.test.Client) sekarang dapat otomatis mengikuti pengalihan dengan argumen `follow` pada [`Client.get()`](/id/6.0/topics/testing/tools/#django.test.Client.get) and [`Client.post()`](/id/6.0/topics/testing/tools/#django.test.Client.post). Ini membuat tampilan percobaan yang menerbitkan pengalihan lebih sederhana.
- Sekarang lebih mudah mendapatkan cetakan konteks di tanggapan mengembalikan percobaan klien: anda akan cukup mengakses konteks sebagai `request.context[key]`. Cara lama, yang memperlakukan `request.context` sebagai dafar konteks, satu untuk setiap cetakan dibangun di rantai warisan, masih tersedia jika anda membutuhkannya.

### Fitur admin baru

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

#### Bidang dapat dirubah pada daftar perubahan

Anda sekarang dapat membuat bidang disunting pada tampilan daftar admin melalui pilihan admin [list\_editable](/id/6.0/ref/contrib/admin/#admin-list-editable) baru. Bidang-bidang ini akan menampilkan widget formulir pada daftar halaman, dan dpat disunting dan disimpan dalam jumlah besar.

#### Admin "actions"

Anda sekarang dapat menentukan [admin actions](/id/6.0/ref/contrib/admin/actions/) yang dapat melakukan beberapa tindakan pada sekelompok model dalam jumlah besar. Pengguna akan dapat memilih obyek pada perubahan daftar halaman dan kemudian memberlakukan tindakan dalam jumlah besar ini pada semua obyek terpilih.

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

### Pengolahan tampilan bersyarat

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

### Namespace URL

Django 1.1 memperbaiki [named URL patterns](/id/6.0/topics/http/urls/#naming-url-patterns) dengan perkenalan dari URL "namespaces."

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

Untuk rincian penuh, lihat [the documentation on defining URL namespaces](/id/6.0/topics/http/urls/#topics-http-defining-url-namespaces).

### GeoDjango

In Django 1.1, [GeoDjango](/id/6.0/ref/contrib/gis/) (i.e.
`django.contrib.gis`) has several new features:

- Dukungan untuk [SpatiaLite](https://www.gaia-gis.it/gaia-sins/) -- basisdata spasial untuk SQLite -- sebagai backend spasial.
- Pengumpulan geografis pernyataan (`Collect`, `Extent`, `MakeLine`, `Union`) dan `F`.
- Metode `GeoQuerySet` baru: `collect`, `geojson`, dan `snap_to_grid`.
- Daftar antarmuka metode baru dari obyek `GEOSGeometry`.

Untuk lebih rinci, lihat dokumentasi GeoDjango.

### Perbaikan lain

Fitur baru dan perubahan diperkenalkan sejak Django 1.0 termasuk:

- [CSRF protection middleware](/id/6.0/ref/csrf/) telah dipisah menjadi dua kelas -- `CsrfViewMiddleware` memeriksa permintaan datang, dan `CsrfResponseMiddleware` mengolah tanggapan keluar. Paduan kelas `CsrfMiddleware` (yang melakukan keduanya) tetap untuk kesesuaian-kebelakang, tetapi menggunakan kelas-kelas terpisah sekarang dianjurkan agar mengizinkan kendali jaringan-halus dari ketika dan dimana pengolahan CSRF mengambil tempat.+
- reverse()\` dan kode yang menggunakannya (sebagai contoh, etiket cetakan `{% url %}`) sekarang bekerja dengan URL di situs administratif Django, asalkan URL admin disetel melalui `include(admin.site.urls)` (mengirim permintaan admin ke tampilan `admin.site.root` masih bekerja, tetapi URL di admin tidak akan "reversible" ketika mengkonfigurasi cara ini).
- Fungsi `include()` di modul Django URLconf sekarang dapat menerima urutan dari pola URL (dibangkitkan oleh `patterns()`) sebagai tambahan ke nama modul.
- Contoh dari formulir Django (lihat [the forms overview](/id/6.0/topics/forms/)) sekarang mempunyai dua metode tambahan, `hidden_fields()` dan `visible_fields()`, yang mengembalikan daftar dari tersembunyi -- yaitu, `<input type="hidden">` -- dan bidang-bidang nampak pada formulir, masing-masing.
- Tampilan umum `redirect_to` sekarang menerima sebuah argumen kata kunci tambahan `permanent`. Jika `permanent` adalah `True`, tampilan akan mengeluarkan pengalihan tetap HTTP (kode keadaan 301). Jika `False`, tampilan akan mengeluarkan pengalihan sementara HTTP (kode keadaan 302).
- Jenis pencarian basisdata baru -- `week_day` -- telah ditambahkan untuk `DateField` dan `DateTimeField`. Jenis ini dari pencarian menerima angka diantara 1 (Minggu) dan 7 (Sabtu), dan mengembalikan sebuah obyek dimana nilai bidang cocok hari itu dari minggu. Lihat [the full list of lookup types](/id/6.0/ref/models/querysets/#field-lookups) untuk rincian.
- Etiket `{% for %}` di bahasa cetakan Django sekarang menerima sebuah pilihan klausa `{% empty %}`, untuk ditampilkan ketika `{% for %}` diminta berputar terhadap urutan kosong. Lihat [the list of built-in template tags](/id/6.0/ref/templates/builtins/) untuk contoh dari ini.
- Perintah pengelolaan [`dumpdata`](/id/6.0/ref/django-admin/#django-admin-dumpdata) sekarang menerima nama model tersendiri sebagai argumen, mengizinkan anda untuk mengekspor data cukup dari model tertentu.
- Ada cetakan penyaring [`safeseq`](/id/6.0/ref/templates/builtins/#std-templatefilter-safeseq) baru yang bekerja seperti [`safe`](/id/6.0/ref/templates/builtins/#std-templatefilter-safe) untuk daftar, menandai setiap barang di daftar sebagai safe.
- [Cache backends](/id/6.0/topics/cache/) sekarang mendukung perintah `incr()` dan `decr()` untuk menaikkan dan menurunkan nilai dari kunci tembolok. Pada backend tembolok yang mendukung menaik/menurun kecil -- paling terutama, memcache backend -- tindakan ini akan menjadi kecil, dan sangat cepat.
- Django now can [easily delegate authentication to the web server](/id/6.0/howto/auth-remote-user/) via a new authentication backend that supports
  the standard `REMOTE_USER` environment variable used for this purpose.
- Ada fungsi [`django.shortcuts.redirect()`](/id/6.0/topics/http/shortcuts/#django.shortcuts.redirect) baru yang membuatnya lebih mudah mengeluarkan pengalihan yang diberikan sebuah obyek, nama tampilan, atau URL.
- Backend `postgresql_psycopg2` sekarang mendukung [native PostgreSQL autocommit](/id/6.0/ref/databases/#postgresql-notes). Ini merupakan lanjutan, fitur khusus-PostgreSQL, yang dapat membuat aplikasi tertentu membaca-berat menjadi lebih cepat.

## Apa Selanjutnya?

We'll take a short break, and then work on Django 1.2 will begin -- no rest for
the weary! If you'd like to help, discussion of Django development, including
progress toward the 1.2 release, takes place daily on the [django-developers](/id/6.0/internals/mailing-lists/#django-developers-mailing-list)
mailing list and in the `#django-dev` IRC channel on `irc.libera.chat`.
Feel free to join the discussions!

Dokumentasi daring Django juga menyertakan petunjuk pada bagaimana membantu Django:

- [How to contribute to Django](/id/6.0/internals/contributing/)

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

Dan itulah cara itu.