Seperti di tulisan sebelumnya model ini bertugas sebagai abstraksi data dari app ke database. Di tulisan ini saya mencoba untuk menuliskan ulang apa yang saya pahami terkait models di django.
Data di model ini akan merepresentasikan data yang ada di database, ambil contoh sebuah app blog misalnya, di app blog kita membutuhkan sebuah artikel yang artikel itu minimal berisi, judul, konten, tanggal dibuat, status nya tayang (publish) atau tidak, maka dari model kita buat seperti ini.
Struktur model di atas itu nantinya akan menjadi tabel dengan nama “articles_articles” dengan isi field seperti yang ditulis di model
default penamaan tabel dari django adalah “app_namamodel”
jika tidak disebutkan primary key django akan membuat field id sebagai primary key secara default
Fields
Seperti contoh di atas, saat membuat model selain mendeklarasikan namanya kita juga mendeklarasikan tipe fieldnya, tipe field ini merepresentasikan 2 hal: tipe data di database dan tipe input di form
Mengacu pada contoh di atas, saat buat field dengan tipe Charfield maka di database akan dibuatkan field dengan tipe varchar, contoh di atas itu akan membuat field di database tipe varchar dengan limit 50 karakter. Sedangkan di level form akan membuat input type text dengan limit karakter 50.
Field Options
Jika kita ingin memberi seperti validasi atau sifat tertentu kepada fields, maka field option ini salah satu caranya, field option sendiri ada beberapa, diantaranya:
Null: Opsi field ini berhubungan langsung dengan database, jika kita set null=True maka di database data field ini diperbolehkan kosong, django sendiri set defaultnya sebagai false
Blank: Field ini mirip dengan null tapi ini untuk di level form, jadi misalkan kista set null=True agar bisa kosong di database tapi jika input melalui form wajib diisi maka blank adalah opsinya, defaultnya sendiri itu False. Contohnya seperti ini, jika kita punya table account yang isinya name, email, password dan telepon tapi di form register hanya mengisi name, email dan password maka field telepon akan boleh null, tapi saat user update profile field telepon ini di level form jadi wajib diisi.
Choices: Opsi ini memungkinan mengubah bentuk field di from dari misal charfield menjadi dropdown, digunakan misal jika kita membuat pilihan yang tidak membutuhkan foreign key, contoh kita punya 3 status draft, review, publish kita tidak perlu bikin 1 tabel sebagai master status tapi kita bisa manfaatkan opsi choices ini. Bisa dilihat di model articles di atas.
Default: Opsi ini memungkinkan kita mengisi nilai default jika fieldnya tidak diisi, misal jika status artikel tidak diisi maka defaultnya draft
Unique: Membuat isi field yang diberi opsi ini unique sehingga tidak boleh ada data yang sama, cobtoh yang sering digunakan adalah username, email, phone number.
Verbose_name: Membuat display label di form dengan nama yang ditentukan. Defaulnya label nama di form akan mengikuti nama field, jika kita isi verbose_name, maka label di form bisa berbeda dengan nama field
Beberapa komparasi fields model antara database dan forms
Relationship
Dalam konsep relational database ada yang dinamakan foreign key (selanjutnya FK), sederhananya FK ini sebagai penanda hubungan antara satu tabel dengan yang lainnya. Di django sendiri kita bisa membuat fk sesuai dengan relasi yang dibutuhkan
One To One
Relasi one to one ini maksudnya satu data di tabel punya relasi dengan satu data di tabel lainnya, contoh paling gampangnya adalah user account dan user profile
Misal kita punya tabel user account yang isinya hanya email, password. Sedangkan user profile lebih lengkap dengan informasi lainnya, sehingga dengan relasi ini sudah pasti 1 akun hanya akan memiliki 1 profile dan begitu pula sebaliknya.
Selain menggunakan relasi one on field explisit di modelnya, kita bisa juga menggunakan inheritance dari model parentnya
One To Many atau Many to One
Relasi ini maksudnya satu data dari satu tabel memungkinkan untuk punya relasi ke banyak data di tabel lainnya, begitupun sebaliknya, contoh paling umum adalah artikel dan kategori
1 Kategori bisa memiliki banyak artikel, dan 1 artikel hanya bisa memiliki 1 kategori
Di django untuk deklarasi many to one bisa menggunakan field foreign key
Many to Many
Relasi in maksudnya banyak data di satu tabel punya relasi dengan banyak tabel di tabel lainnya. Salah satu contohnya adalah sebuah artikel bisa memiliki banyak tags, dan satu tags bisa dimiliki banyak artikel, sehingga gambaran diagramnya seperti ini
Relasi antar app
Dalam satu berkas model bisa ada beberapa “model” name, misal di blog model kita bisa setup 2 model name, kategori dan artikel
Tapi contoh di atas masih dalam satu app, bagaimana jika ingin menambahkan relasi creatornya yang berelasi ke user yang login. Pertama yang paling mudah yaitu dengan kita import model yang akan kita jadikan parent.
Ada satu cara lagi yaitu dengan “string”, formatnya seperti di bawah ini
Migration
Di atas disebutkan bahwa model ini menggambarkan struktur tabel di django, tapi tidak serta merta saat kita buat model itu akan membuat tabel, agar model bisa berubah jadi tabel ada dua tahap yang diperlukan: makemigrations dan migrate
Makemigrations
Django mempunyai beberapa fungsi command line untuk berinteraksi dengan projek dan app yang kita buat, salah duanya yaitu makemigrations dan migrate.
Makemigrations ini singkatnya adalah perintah untuk membuat struktur model menjadi struktur atau statement yang akan diterjemahkan menjadi perintah sql di “belakang layar”/
Saat kita jalankan perintah ./manage.py makemigrations nama-app, maka akan keluar output seperti di bawah ini
Perintah di atas akan menghasil satu berkas di folder migration, biasanya jika pertama kali melakukan make migration nama filenya punya format no_urut_nama_model.py
Migrate
Perintah kedua adalah migrate, jika perintah makemigrations itu hanya membuat file di folder migrations maka perintah migrate adalah perintah yang menjlankan fungsi untuk membuat table ke database yang dituju.
Sederhananya flow yang terjadi seperti berikut
> model dibuat
> makemigration akan menghasilkan berkas “skema”
> migrate akan menjalankan perintah “create table ….” berdasarkan skema yang ada
> tabel tersedia
Sebenarnya masih ada yang ingin saya tulis terkait model, tapi mungkin akan jauh lebih masuk akal kalau ditulis jika sudah menulis terkait admin atau forms.