Dokumentasi model acuan menjelaskan bagaimana menggunakan kelas-kelas bidang standar Django -- CharField, DateField, dll. Untuk banyak tujuan, kelas-kelas tersebut adalah yang anda akan butuhkan. Terkadang, meskipun, versi DJango tidak akan bertemu persyaratan tepat anda, atau anda akan menggunakan sebuah bidang yang seluruhnya berbeda dari yang dikemas dengan Django.
Jenis bidang siap pakai Django tidak mencangkup setiap jenis kolom basisdata yang mungkin -- hanya jenis umum, seperti VARCHAR dan INTEGER. Untuk lebih mengaburkan jenis kolom, seperti poligon geografis atau bahkan jenis dibuat-pengguna seperti PostgreSQL custom types, anda dapat menentukan subkelas-subkelas Field Django and sendiri.
Jalan lain, anda mungkin mempunyai obyek Python rumit yang dapat entah bagaimana disambungkan untuk cocok kedalam jenis kolom basisdata standar. Ini adalah kasus lain dimana sebuah subkelas Field akan membantu anda menggunakan obyek anda dengan model anda.
Membuat penyesuaian bidang membuatuhkan sedikit perhatian ke rincian. Untuk membuat hal-hal lebih mudah utnuk diikuti, kami akan menggunakan contoh tetap melalui dokumen ini: membungkus sebuah obyek Python mewakili persetujuan dari kartu-kartu dalam sebuah tangan dari Bridge. Jangan khawatir, anda tidak perlu mengetahui bagaimana bermain Bridge untuk mengikuti contoh ini. Anda hanya perlu mengetahui bahwa 52 kartu dibagikan sama ke empat pemain, yang secara tradisional dipanggil utara, timur, selatan dan barat. Kelas kami kelihatan seperti ini:
\nclass Hand(object):\n """A hand of cards (bridge style)"""\n\n def __init__(self, north, east, south, west):\n # Input parameters are lists of cards ('Ah', '9s', etc.)\n self.north = north\n self.east = east\n self.south = south\n self.west = west\n\n # ... (other possibly useful methods omitted) ...\nIni hanyalah kelas Python asli, dengan tidak ada spesifik-Django tentangnya. Kami akan dapat melakukan hal-hal seperti ini dalam model kami (kami menganggap atribut hand pada model adalah sebuah instance dari Hand):
example = MyModel.objects.get(pk=1)\nprint(example.hand.north)\n\nnew_hand = Hand(north, east, south, west)\nexample.hand = new_hand\nexample.save()\nKami memberikan dan mengambil dari atribut hand dalam model kami seperti kelas Python lainnya. Tipuannya adalah mengatakan Django bagaimana menangani penyimpanan dan memuat sebuah obyek seperti itu.
Agar menggunakan kelas Hand di model kami, kami tidak harus merubah kelas ini sama sekali. Ini adalah cocok, karena dia berarti anda dapat dengan mudah menulis model mendukung kelas-kelas yang ada dimana anda tidak dapat merubah sumber kode.
Jalan paling sederhana memikirkan sebuah bidang model adalah dia menyediakan sebuah jalan untuk mengambil sebuah obyek Pyton biasa -- string, boolean, datetime, atau sesuatu lebih rumit seperti Hand -- dan merubahnya ke dan dari sebuah bentuk yang berguna ketika berhubungan dengan basisdata (dan penyambungan, tetapi, seperti yang akan kita lihat nanti, yang jatuh keluar secara alami sekali anda mempunyai sisi basisdata dibawah kendali).
Bidang dalam sebuah model harus bagaimanapun dipindahkan untuk cocok kedalam jenis kolom basisdata yang ada. Basisdata yang berbeda menyediakan kumpulan berbeda dari jenis kolom sah, tetapi aturan masih sama: yaitu hanya jenis anda harus bekerja dengannya. Apapun anda ingin simpan dalam basisdata harus cocok kedalam satu dari jenis itu.
\nBiasanya, anda antara menulis sebuah bidang Django untuk mencocokkan jenis kolom basisdata tertentu, atau ada jalan cukup mudah untuk merubah data anda menjadi, katakan, sebuah deretan karakter.
\nUntuk contoh Hand kami, kami dapat merubah kartu data menjadi deretan karakter dari 104 karakter dengan menambah semua kartu bersama-sama dalam yang telah ditetapkan sebelumnya -- katakan, semua kartu utara dahulu, kemudian kartu timur, selatan dan barat. Hadi obyek Hand dapt disimpan ke kolom teks atau karakter dalam basisdata.
Semua bidang Django (dan ketika kami katakan bidang dalam dokumen ini, kami selalu berarti bidang model dan bukan bidang formulir) adalah subkelas dari django.db.models.Field. Kebanyakan informasi yang Django rekam mengenai sebuah bidang adalah umum bagi semua teman -- nama, bantuan, teks, keunikan dan sebagainya. Menyimpan semua informasi itu yang ditangani oleh Field. Kami akan memasuki rincian tepat dari Field apa yang dapat dilakukan kemudian; untuk sekarang, cukuplah untuk mengatakan bahwa segala sesuatu turun dari Field dan kemudian menyesuaian potongan kunci dari kebiasaan kelas.
Adalah penting untuk menyadari bahwa sebuah kelas bidang Django bukan apa yang disimpan dalam atribut model anda. Pengaturan model mengandung obyek Python biasa. Kelas-kelas bidang yang anda tentukan dalam sebuah model sebenarnya disimpan dalam kelas Meta ketika kelas model dibuat (rincian tepatnya bagaimana ini dilakukan adalah tidak penting disini). Ini karena kelas-kelas bidang tidak perlu ketika anda hanya membuat dan merubah atribut. Sebagai gantinya, mereka menyediakan mesin-mesin untuk merubah diantara nilai atribut dan apa yang disimpan dalam basisdata atau dikirim ke serializer.
Ingatlah ini ketika membuat penyesuaian bidang sendiri. Subkelas Field Django anda tulis menyediakan mesin-mesin untuk merubah diantara instance Python anda dan nilai database/serializer dalam beragam cara (ada perbedaan diantara menyimpan sebuah nilai dan menggunakan sebuah nilai untuk pencarian, sebagai contoh). Jika ini terdengar sedikit rumit, jangan khawatir -- dia akan menjadi lebih jelas dalam contoh dibawah ini. Ingatlah bahwa anda akan sering membuat dua kelas ketika anda ingin penyesuaian bidang:
Kelas pertama adalah obyek Python dimana pengguna anda akan merubah. Mereka akan menetapkannya ke atribut model, mereka akan membaca darinya untuk menampilkan tujuan, hal-hal seperti itu. ini adalah kelas hand dalam contoh kami.
Kelas kedua adalah subkelas Field. Ini adalah kelas yang diketahui bagaimana merubah kelas pertama anda ke belakang dan seterusnya diantara bentuk penyimpanan tetap dan bentuk Python.
Ketika merencanakan subkelas Field anda, pertama berikan beberapa diduga yang mana ada kelas Field bidang baru anda yang paling mirip. Dapatkah anda mensubkelaskan bidang Django yang ada dan menyimpan diri anda beberapa pekerjaan? Jika tidak, anda harus mensubkelaskan kelas Field, yang semuanya turun.
Inisialisasi bidang baru anda adalah sebuah masalah dari memisahkan argumen apapun yang khusus pada kasus anda dari argumen umum dan melewatkannya ke cara __init__()` dari Field (atau kelas induk anda).
Dalam contoh kami, kami akan memanggil bidang HandField. (Adalah ide bagus untuk memanggil subkelas Field anda <Something>Field, sehingga sangat mudah dicirikan sebagai sebuah subkelas Field.) Dia tidak berperilaku seperti bidang lainnya yang ada, jadi kami akan mensubkelaskan secara langsung dari Field:
from django.db import models\n\nclass HandField(models.Field):\n\n description = "A hand of cards (bridge style)"\n\n def __init__(self, *args, **kwargs):\n kwargs['max_length'] = 104\n super(HandField, self).__init__(*args, **kwargs)\nHandField kami menerima kebanyakan pilihan bidang standar (lihat daftar dibawah ini), tetapi kami memastikan dia mempunyai panjang tetap, sejak dia hanya butuh menampung 52 nilai kartu ditambah pasangan mereka; 104 karakter jumlahnya.
Cara Field.__init__() mengambil parameter berikut:
nama
rel: Digunakan untuk bidang terkait (seperti ForeignKey). Hanya untuk penggunaan lanjut.
attr:~django.db.models.Field.default
serialize: Jika False, bidang tidak akan didisambungkan ketika model dilewatkan ke serializers Django. Nilai awal ke True.
db_tablespace: hanya untuk pembuatan indeks, jika dukungan backend tablespaces. Anda dapat biasanya mengabaikan pilihan ini.
auto_created: True jika bidang otomatis telah dibuat, adapun OneToOneField digunakan oleh warisan model. Untuk penggunaan hanya tingkat lanjut.
Semua pilihan tanpa sebuah penjelasan dalam daftar diatas mempunyai arti yang sama mereka lakukan untuk bidang Django biasa. Lihat field documentation untuk contoh dan rincian.
\nKontrapung untuk menulis cara __init__() anda adalah menulis cara deconstruct(). Cara ini mengatakan Django bagaimana mengambil instance dari bidang baru anda dan menguranginya untuk sebuah formulir yang disambungkan - khususnya, argumen apa utnuk dilewatkan ke __init__() untuk membuatnya kembali.
Jika anda belum menambahkan pilihan tambahan pada bagian atas bidang anda warisi, lalu tidak perlu untuk menulis cara deconstruct() baru. Jika, bagaimanapun, anda sedang merubah argumen dilewati dalam __init__() (seperti kami dalam HandField), anda akan butuh tambahan nilai yang sedang dilewati.
Kontrak dari deconstruct() adalah sederhana; dia mengembalikan sebuah tuple dari empat barang: nama atribut bidang, jalur impor penuh dari kelas bidang, penempatan argumen (sebagai sebuah daftar), dan argumen kata kunci (sebagai pendiktean). Catat bahwa ini berbeda dari cara deconstruct() for custom classes yang mengembalikan sebuah tuple dari tiga hal.
Sebagai sebuah penyesuaian bidang penulis, anda tidak perlu memperhatikan tentang dua nilai pertama; kelas Field dasar mempunyai semua kode untuk bekerja nama atribut bidang dan mengimpor jalur. Anda, bagaimanapun, harus memperhatikan tentang penempatan dan katakunci argumen, seperti ini mirip hal-hal anda sedang rubah.
Sebagai contoh, dalam kelas HandField kami selalu memaksa menyetel max_length dalam __init__(). Cara deconstruct() dalam basis kelas Field akan melihat ini dan mencoba mengembalikannya dalam argumen katakunci; demikian, kami dapat membuangnya dari argumen katakunci untuk kesiapan:
from django.db import models\n\nclass HandField(models.Field):\n\n def __init__(self, *args, **kwargs):\n kwargs['max_length'] = 104\n super(HandField, self).__init__(*args, **kwargs)\n\n def deconstruct(self):\n name, path, args, kwargs = super(HandField, self).deconstruct()\n del kwargs["max_length"]\n return name, path, args, kwargs\nJika anda menambahkan argumen kata kunci, anda perlu menuliskan sendiri kode untuk menambahkan nilai ke kwargs
from django.db import models\n\nclass CommaSepField(models.Field):\n "Implements comma-separated storage of lists"\n\n def __init__(self, separator=",", *args, **kwargs):\n self.separator = separator\n super(CommaSepField, self).__init__(*args, **kwargs)\n\n def deconstruct(self):\n name, path, args, kwargs = super(CommaSepField, self).deconstruct()\n # Only include kwarg if it's not the default\n if self.separator != ",":\n kwargs['separator'] = self.separator\n return name, path, args, kwargs\nContoh lebih rumit diluar cakupan dari dokumen ini, tetapi ingat - untuk konfigurasi apapun dari instance Field anda, deconstruct() harus mengembalikan argumen yang anda dapat lewati ke __init__ untuk membangun kembali keadaan tersebut.
Beri perhatian lebih jika anda menyetel nilai baru awal untuk argumen dalam super kelas Field; anda ingin memastikan mereka selalu disertakan, daripada menghilang jika mereka mengambil nilai awal lama.
Dalam tambahan, coba untuk menghindari nilai kembalian sebagai argumen penempatan; jika memungkinkan, kembalikan nilai sebagai argumen katakunci untuk kesesuaian masa depan maksimal. Tentu saja, jika anda merubah nama dari hal-hal sering daripada penempatan mereka dalam daftar argumen pembangun, anda mungkin memilih penempatan, tetapi ingatlah bahwa orang akan membangun kembali bidang ada dari versi bersambung untuk sejenak (mungkin tahunan), tergantung berapa lama perpindahan langsung anda.
\nAnda dapat melihat hasil dari membongkar dengan mencari dalam perpindahan yang menyertakan bidang, dan anda dapat menguji pembongkaran dalam satuan percobaan dengan hanya membongkar dan membangun kembali bidang.
\nname, path, args, kwargs = my_field_instance.deconstruct()\nnew_instance = MyField(*args, **kwargs)\nself.assertEqual(my_field_instance.some_attribute, new_instance.some_attribute)\nYou can't change the base class of a custom field because Django won't detect\nthe change and make a migration for it. For example, if you start with:
\nclass CustomCharField(models.CharField):\n ...\nand then decide that you want to use TextField instead, you can't change\nthe subclass like this:
class CustomCharField(models.TextField):\n ...\nInstead, you must create a new custom field class and update your models to\nreference it:
\nclass CustomCharField(models.CharField):\n ...\n\nclass CustomTextField(models.TextField):\n ...\nAs discussed in removing fields, you\nmust retain the original CustomCharField class as long as you have\nmigrations that reference it.
Seperti biasa, anda harus mendokumentasikan jenis bidang anda, sehingga pengguna akan mengetahui apa itu. Dalam tambahan untuk menyediakan docstring untuknya, mana yang berguna untuk pengembang, anda dapat juga mengizinkan aplikasi admin untuk melihat gambaran pendek dari jenis bidang melalui aplikasi django.contrib.admindocs. Untuk melakukan ini cukup menyediakan gambaran teks dalam sebuah atribut kelas description dari bidang penyesuaian anda. Dalam contoh diatas, gambaran ditampilkan oleh aplikasi admindocs untuk sebuah HandField akan menjadi 'Sebuah tangan dari kartu (gaya bridge)'.
Dalam tampilan django.contrib.admindocs, gambaran bidang ditambahkan dengan field.__dict__ yang mengizinkan gambaran pada argumen yang digabungkan dari bidang. Sebagai contoh, gambaran untuk CharField adalah:
description = _("String (up to %(max_length)s)")\nSekali anda telah membuat subkelas Field anda, anda boleh mempertimbangkan mengesampingkan sedikit cara standar, tergantung pada kebiasaan bidang anda. Daftar dari cara dibawah ini adalah dalam lebih kurang menurun urutan dari kepentingan, jadi mulai dari atas.
Katakan anda telah membuat jenis penyesuaian PostgreSQL dipanggil mtype. Anda dapat mensubkelaskan Field dan menerapkan cara db_type(), seperti begitu:
from django.db import models\n\nclass MytypeField(models.Field):\n def db_type(self, connection):\n return 'mytype'\nSekali anda mempunyai MytypeField, anda dapat menggunakannya di model apapun, seperti jenis Field apapun lainnya
class Person(models.Model):\n name = models.CharField(max_length=80)\n something_else = MytypeField()\nJika anda menuju membangun aplikasi agnostik-basisdata, anda harus melaporkan untuk perbedaan dalam jenis kolom basisdata. Sebagai contoh, jenis kolom date/time dalam PostgreSQL dipanggil timestamp, sementara kolom yang sama dalam MySQL dipanggil datetime. Jalan termudah untuk menangani ini dalam cara db_type() adalah untuk memeriksa atribut connection.settings_dict['ENGINE'].
Sebagai contoh:
\nclass MyDateField(models.Field):\n def db_type(self, connection):\n if connection.settings_dict['ENGINE'] == 'django.db.backends.mysql':\n return 'datetime'\n else:\n return 'timestamp'\nCara db_type() dipanggil oleh Django ketika kerangka membangun pernyataan CREATE TABLE untuk aplikasi anda -- yaitu, ketika anda pertama kali membuat tabel anda. Dia juga dipanggil ketika membangun klausa WHERE yang menyertakan bidang model -- yaitu, ketika anda mengambil data menggunakan cara QuerySet seperti get(), filter(), dan exclude() dan mempunyai bidang model sebagai sebuah argumen. Dia tidak dipanggil pada lain waktu, jadi dia dapat mampu menjalankan sedikit kode rumit , seperti connection.settings_dict diperiksa dalam contoh diatas.
Beberapa jenis kolom basisdata menerima parameter, seperti CHAR(25), dimana parameter 25 mewakili panjang kolom maksimum. Dalam kasus seperti ini, dia lebih supel jika parameter ditentukan dalam model daripada menjadi kode-keras dalam cara db_type(). Sebagai contoh, dia tidak akan masuk akan untuk mempunyai CharMaxlength25Field, ditampilkan disini:
# This is a silly example of hard-coded parameters.\nclass CharMaxlength25Field(models.Field):\n def db_type(self, connection):\n return 'char(25)'\n\n# In the model:\nclass MyModel(models.Model):\n # ...\n my_field = CharMaxlength25Field()\nJalan lebih baik dari mengerjakan ini adalah membuat parameter dapat lebih khusus pada wktu berjalan -- yaitu, ketika kelas dipakai. Untuk melakukan itu, cukup terapkan Field.__init__(), seperti begitu:
# This is a much more flexible example.\nclass BetterCharField(models.Field):\n def __init__(self, max_length, *args, **kwargs):\n self.max_length = max_length\n super(BetterCharField, self).__init__(*args, **kwargs)\n\n def db_type(self, connection):\n return 'char(%s)' % self.max_length\n\n# In the model:\nclass MyModel(models.Model):\n # ...\n my_field = BetterCharField(25)\nAkhirnya, jika kolom anda membutuhkan pengaturan SQL yang rumit, kembalikan None dari db_type(). Ini akan menyebabkan kode pembuatan SQL Django melewati terhadap bidang ini. Anda kemudian bertanggung jawab untuk membuat kolom dalam tabel yang benar dalam cara lain, tentu saja, tetapi ini memberikan anda sebuah jalan untuk memberitahu Django untuk keluar dari jalan.
Jika penyesuaian kelas Field anda berhubungan dengan struktur dara yang lebih rumit daripada deretan karakter, tanggal, integer, atau float, kemudian anda butuh untuk mengesampingkan from_db_value() dan to_python().
Jika ada untuk bidang subkelas, from_db_value() akan dipanggil dalam semua keadaan ketika data dimuat dari basisdata, termasuk dalam keseluruhan dan panggilan values().
to_python() dipanggil dengan memutuskan dan selama cara clean() digunakan dari formulir.
Sebagai aturan umum, to_python() harus berurusan secara anggun dengan salah satu dari argumen berikut:
Sebuah instance dari jenis yang benar (sebagai contoh, Hand dalam contoh kami yang sedang berjalan).
Sebuah string
None (jika bidang mengizinkan null=True)
Dalam kelas HandField, kami menyimpan data sebagai bidang VARCHAR dalam basisdata, jadi kami butuh dapat mengolah deretan karakter dan None dalam from_db_value(). Di to_python(), kami butuh juga menangani instance Hand:
import re\n\nfrom django.core.exceptions import ValidationError\nfrom django.db import models\nfrom django.utils.translation import ugettext_lazy as _\n\ndef parse_hand(hand_string):\n """Takes a string of cards and splits into a full hand."""\n p1 = re.compile('.{26}')\n p2 = re.compile('..')\n args = [p2.findall(x) for x in p1.findall(hand_string)]\n if len(args) != 4:\n raise ValidationError(_("Invalid input for a Hand instance"))\n return Hand(*args)\n\nclass HandField(models.Field):\n # ...\n\n def from_db_value(self, value, expression, connection, context):\n if value is None:\n return value\n return parse_hand(value)\n\n def to_python(self, value):\n if isinstance(value, Hand):\n return value\n\n if value is None:\n return value\n\n return parse_hand(value)\nPerhatikan bahwa kami selalu mengembalikan sebuah instance hand dari cara ini. Itu adalah jenis obyek Python kami ingin simpan dalam atribut model.
Untuk to_python(), jika apapun berjalan salah selama perubahan nilai, anda harus memunculkan pengecualian ValidationError.
Sejak menggunakan sebuah basisdata membutuhkan perubahan dalam kedua jalan, jika anda mengesampingkan to_python() anda juga harus mengesampingkan get_prep_value() untuk merubah obyek Python kembali ke nilai permintaan.
Sebagai contoh:
\nclass HandField(models.Field):\n # ...\n\n def get_prep_value(self, value):\n return ''.join([''.join(l) for l in (value.north,\n value.east, value.south, value.west)])\nBeberapa jenis data (sebagai contoh, tanggal) butuh dalam bentuk yang khusus sebelum mereka dapat digunakan oleh backend basisdata. get_db_prep_value() adalah cara dimana perubahan tersebut harus dibuat. Hubungan khusus yang akan digunakan untuk permintaan dilewati sebagai parameter connection. Ini mengizinkan anda menggunakan logika perubahan khusus-backend jika dia diwajibkan.
Sebagai contoh, Django menggunakan cara berikut untuk BinaryField nya:
def get_db_prep_value(self, value, connection, prepared=False):\n value = super(BinaryField, self).get_db_prep_value(value, connection, prepared)\n if value is not None:\n return connection.Database.Binary(value)\n return value\nDalam kasus bidang penyesuaian anda butuh perubahan khusus ketika sedang disimpan yang tidak sama seperti perubahan digunakan untuk parameter permintaan biasa, anda dapat mengesampingkan get_db_prep_save().
Jika anda ingin prapengolahan nilai sebelum menyimpan, anda dapat menggunakan pre_save(). Sebagai contoh, DateTimeField Django menggunakan cara ini untuk menyetel atribut dengan benar dalam kasus dari auto_now atau auto_now_add.
Jika anda melakukan mengesampingkan cara ini, anda harus mengembalikan nilai dari atribut di akhirnya. Anda harus juga memperbaharui atribut model jika anda membuat perubahan apapun ke nilai sehingga kode menahan acuan ke model akan selalu melihat nilai benar.
\nSeperti perubahan nilai, menyiapkan sebauh nilai untuk pencarian basisdata adalah dua tingkatan pengolahan.
\nget_prep_lookup() melakukan tingkatan pertama dari persiapan pencarian: mengetik perubahan dan menmeriksa data.
Menyiapkan value untuk dilewatkan ke basisdata ketika digunakan dalam pencarian (sebuah pembatas WHERE dalam SQL). Parameter lookup_type akan menjadi satu dari pencarian penyaring Django sah: exact, iexact, contains, icontains, gt, gte, lt, lte, in, startswith, istartswith, endswith, iendswith, range, year, month, day, isnull, search, regex, dan iregex.
Jika anda sedang menggunakan pencarian penyesuaian, lookup_type dapat menjadi lookup_name apapun digunakan oleh pencarian penyesuaian proyek.
Cara anda harus dipersiapkan untuk menangani semua nilai lookup_type ini dan harus menampilkan salah satu sebuah ValueError jika value dari urutan salah (sebuah daftar anda harapkan sebuah obyek, sebagai contoh) atau TypeError jika bidang anda tiadk mendukung jenis tersebut dari pencarian. Untuk banyak bidang-bidang, anda dapat mendapatkannya dengan menangani jenis pencarian yang butuh penanganan khusus untuk bidang anda dan sisa ke cara get_db_prep_lookup() dari kelas induk.
Jika anda butuh untuk menerapkan get_db_prep_save(), anda akan biasanya butuh menerapkan get_prep_lookup(). Jika anda tidak, get_prep_value() akan dipanggil secara awal penerapan, untuk mengelola pencarian exact, gt, gte, lt, lte, in dan range.
Anda juga ingin menerapkan cara ini untuk membatasi jensi pencarian yang dapat digunakan dengan jenis bidang penyesuaian anda.
\nCatat bahwa, untuk pencarian "jangkauan" dan "dalam", get_prep_lookup akan menerima sebuah daftar dari obyek (barangkali dari jenis yang benar) dan akan merubah mereka ke sebuah daftar dari jenis benar untuk melewatkan ke basisdata. Kebanyakan dari waktu, anda dapat menggunakan kembali get_prep_value(), atau setidaknya faktor luar beberapa potongan umum.
Sebagai contoh, kode berikut menerapkan get_prep_lookup untuk membatasi jenis pencarian yang diterima terhadap exact dan in:
class HandField(models.Field):\n # ...\n\n def get_prep_lookup(self, lookup_type, value):\n # We only handle 'exact' and 'in'. All others are errors.\n if lookup_type == 'exact':\n return self.get_prep_value(value)\n elif lookup_type == 'in':\n return [self.get_prep_value(v) for v in value]\n else:\n raise TypeError('Lookup type %r not supported.' % lookup_type)\nUntuk melakukan perubahan data basisdata-khusus dibuatuhkan oleh sebauh pencarian, anda dapat mengesampingkan get_db_prep_lookup().
Untuk menyesuaiakan bidang formulir digunakan oleh ModelForm, anda dapat mengesampingkan formfield().
Kelas bidang formulir dapat ditentukan melalui argumen form_class dan choices_form_class; yang terakhir digunakan jika bidang mempunyai pilihan yang ditentukan, yang depan kebalikannya. Jika argumen ini tidak disediakan, CharField atau TypedChoiceField akan digunakan.
Semua kamus kwargs dilewatkan secara langsung ke formulir cara __init__() bidang. Biasanya, semua anda butuh lakukan adalah menyetel nilai awal bagus untuk form_class argumen (dan mungkin choices_form_class) dan kemudian mengutus penanganan lebih lanjut untuk kelas induk. Ini mungkin membutuhkan anda menulis bidang formulir penyesuaian (dan bahkan sebuah widget formulir). Lihat forms documentation untuk informasi tentang ini.
Melanjutkan contoh berlangsung kita, kami dapat menulis cara formfield() sebagai:
class HandField(models.Field):\n # ...\n\n def formfield(self, **kwargs):\n # This is a fairly standard way to set up some defaults\n # while letting the caller override them.\n defaults = {'form_class': MyFormField}\n defaults.update(kwargs)\n return super(HandField, self).formfield(**defaults)\nIni menganggap kami telah mengimpor kelas bidang MyFormField (yang mempunyai widget awal sendiri). Dokumen ini tidak mencakup rincian dari penulisan bidang formulir penyesuaian.
Jika anda telah membuat cara db_type(), anda tidak butuh khawatir tentang get_internal_type() -- dia tidak akan digunakan. Terkadang, meskipun, penyimpanan basisdata anda mirip dalam jenis pada beberapa bidang lain, jadi anda dapat menggunakan logika bidang lain itu untuk membuat kolum yang benar.
Sebagai contoh:
\nclass HandField(models.Field):\n # ...\n\n def get_internal_type(self):\n return 'CharField'\nTidak penting backend basisdata anda kami gunakan, ini akan berarti bahwa migrate dan perintah SQL lainnya membuat jenis kolom benar untuk menyimpan sebuah deretan karakter.
Jika get_internal_type() megembalikan sebuah deretan karakter yang tidak diketahui ke Django untuk backend basisdata anda sedang gunakan -- yaitu, dia tidak muncul dalam django.db.backends.<db_name>.base.DatabaseWrapper.data_types -- deretan karakter akan masih digunakan oleh penyambung, tetapi cara db_type() awal akan mengembalikan None. Lihat dokumentasi dari db_type() untuk alasan mengapa ini mungkin berguna. menaruh sebuah gambaran deretan karakter kedalam sebagai jenis dari bidang untuk penyambung adalah ide berguna jika anda sedang akan menggunakan keluaran penyambung dalam beberapa tempat lainnya, diluar Django.
Untuk menyesuaikan bagaimana nilai disambung oleh penyambung, anda dapat mengesampingkan value_to_string(). Menggunakan value_from_object() adalah jalan terbaik untuk mendapatkan nilai bidang sebelum penyambungan. Sebagai contoh, sejak HandField kami menggunakan deretan karakter untuk penyimpanan datanya, kami dapat menggunakan kembali beberapa kode perubahan yang ada:
class HandField(models.Field):\n # ...\n\n def value_to_string(self, obj):\n value = self.value_from_object(obj)\n return self.get_prep_value(value)\nMenulis sebuah bidang penyesuaian dapat menjadi pengolahan yang rumit, khususnya jika anda sedang melakukan perubahan rumit diantara jenis Python anda dan basisdata anda dan bentuk penyambungan. Ini adalah sepasang tip utnuk membuat hal-hal berjalan lebih halus:
\nLihat bidang Django yang ada (dalam django/db/models/fields/__init__.py) untuk inspirasi. Coba temukan bidang yang mirip pada apa anda inginkan dan perpanjang dia sedikit, daripada membuat sebuah keseluruhan bidang baru dari awal.
Taruh sebuah cara __str__() (__unicode__() pada Python 2) pada kelas anda sedang bungkus sebagai sebuah bidang. Ada banyak tempat dimana kebiasaan awal dari kode bidang adalah memanggil force_text() pada nilai. (Dalam contoh kami di dokumen ini, value akan menjadi instance Hand, bukan sebuah HandField). Jadi jika cara __str__() anda (__unicode__() pada Python 2) otomatis merubah ke bentuk deretan karakter dari obyek Python anda, anda dapat menyimpan banyak pekerjaan.
FileFieldLink to this heading#Dalam tambahan pada cara diatas, bidang-bidang yang berurusan dengan berkas-berkas mempunyai sedikit persyaratan khusus lainnya yang harus diambil kedalam akun. Kebanyakan dari mekanisme disediakan oleh FileField, seperti mengendalikan penyimpanan basisdata dan pengambilan, dapat tetap tidak berubah, meninggalkan subkelas-subkelas untuk berurusan dengan tantangan dari mendukung jenis khusus dari berkas.
Django menyediakan sebuah kelas File, yang digunakan sebagai sebuah proxy pada isi berkas dan tindakan. Ini dapat disubkelaskan ke menyesuaikan bagaimana berkas diakses, dan cara apa yang tersedia. Dia tinggal di django.db.models.fields.files, dan kebiasaan awalnya adalah dijelaskan dalam file documentation.
Sekali sebuah subkelas dari File dibuat, subkelas FileField harus diberitahu untuk menggunakannya. Untuk melakukannya, cukup tetapkan subkelas File baru ke atribut attr_class khusus dari subkelas FileField.
Sebagai tambahan pada rincian diatas, terdapat sedikit panduan yang dapat meningkatkan efisiensi dan kesiapan dari kode bidang.
\nSumber untuk ImageField sendiri Django (dalam django/db/models/fields/files.py) adalah contoh hebat dari bagaimana untuk mensubkelaskan FileField untuk mendukung jenis khusus dari berkas, karena menggabungkan semua teknik digambarkan diatas.
Menembolok atribut berkas dimanapaun memungkinkan. Sejak berkas-berkas mungkin disimpan dalam sistem penyimpanan jauh, mengambil mereka mungkin memakan waktu tambahan, atau bahkan uang, yang tidak selalu dibutuhkan. Sekali sebuah berkas diambil untuk mendapatkan beberapa data tentang isinya, tembolok sebanyak mungkin data tersebut untuk mengurangi jumlah kali berkas harus diambil pada pemanggilan berikut untuk informasi itu.