Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby

Rekaman aktif: Rails Database jembatan

by
Read Time:21 minsLanguages:

Indonesian (Bahasa Indonesia) translation by graywest (you can also view the original English article)

Di masa lalu, untuk membangun aplikasi web, Anda diperlukan keterampilan untuk kode dalam bahasa logika bisnis Anda dan bahasa database Anda. Baru-baru ini, namun, kerangka back-end yang condong ke arah menggunakan Object-Relational Mapping (ORM); ini adalah teknik yang memungkinkan Anda mengelola database Anda dalam bahasa logika bisnis yang Anda merasa paling nyaman dengan.

Rel menggunakan ORM dalam bentuk Active Record. Dalam tutorial ini, kita akan menyelam ke Active Record dan melihat apa yang bisa lakukan untuk kita!


Apa Active Record itulah,

Seperti saya katakan, Active Record adalah ORM. Ini berarti itu adalah lapisan kode Ruby yang berjalan antara database Anda dan kode logika. Ketika Anda perlu untuk membuat perubahan ke database, Anda akan menulis kode Ruby, dan kemudian jalankan migrasi, yang kami akan meninjau segera. Migrasi ini membuat perubahan yang sebenarnya ke database. Bagian yang keren adalah bahwa tidak peduli apa database menggunakan: rel dapat menangani hampir semua dari mereka. Misalnya, rel menggunakan SQLite lokal saat Anda berkembang. Namun, katakanlah Anda sedang menjalankan untuk Heroku, yang menggunakan PostreSQL. Yang harus Anda lakukan adalah menambahkan ini ke Gemfile Anda:

Sekarang, ketika Anda menyebarkan, Heroku akan menjalankan migrasi yang sama (menggunakan adaptor PostgreSQL). Kode yang sama, database yang berbeda, yang cukup keren, menurut pendapat saya.

Jadi, itu adalah apa Active Record; Mari kita menggali lebih dalam dan melihat bagaimana semuanya bekerja.


Persiapan

Meskipun secara teknis mungkin menggunakan Active Record di luar Rails app, sembilan kali keluar dari sepuluh Anda akan menggunakannya dalam Rails app, sehingga adalah apa yang akan kita lakukan di sini. Saya menggunakan rel 3.2.12, versi terbaru seperti yang saya ketik. Jika Anda punya yang diinstal, Anda dapat memulai dengan menciptakan sebuah aplikasi Rails baru.

Sekarang, kita dapat mulai dengan membuat model.


Membuat model dan migrasi

Seperti Anda mungkin berharap, karena Active Record berinteraksi dengan database, itu adalah the M di Rails' MVC: model. Dari baris perintah, kita akan membuat model untuk, mengatakan, orang. Sebenarnya, rel menghasilkan perintah cukup fleksibel: bekerja semua perintah berikut:

Pertama dua baris di sini melakukan hal yang sama; rel g adalah hanya cara pintas untuk rel menghasilkan. Yang ketiga memberikan Rails sedikit lebih banyak informasi, sehingga sedikit lebih banyak pekerjaan yang bisa lakukan untuk kita. Kami katakan kami ingin model ini memiliki tiga bidang: first_name, last_name, dan usia. Untuk first_name dan last_name, kita tidak menentukan jenis, jadi default untuk string. Untuk usia, kita mengatakan bahwa itu harus integer.

Jadi, apa yang ini benar-benar lakukan? Anda akan melihat beberapa output, menjelaskan bahwa. Bit yang penting adalah ini:

Pertama adalah file migrasi Anda (tentu saja, timestamp akan berbeda); yang kedua adalah kelas Anda Ruby.

Anda harus nyaman dengan sintaks file migrasi, karena Anda akan sering ingin menyesuaikan kode. Mari kita periksa.

Migrasi setiap adalah kelas; yang satu ini memiliki metode tunggal: mengubah. Jika Anda akrab dengan Ruby, ini harus cukup cukup jelas: migrasi ini menciptakan sebuah tabel yang bernama "orang" dalam database. Tabel ini memiliki enam kolom. Benar, enam. Ada first_name, last_name, dan bidang umur kami menambahkan dari baris perintah; dalam create_table blok, kita menggunakan metode bernama setelah data jenis dan melewati mereka simbol dengan nama kolom.

Kemudian, ada t.timestamps. Hal ini menciptakan dua kolom lain di meja kami: created_at dan updated_at. Tentu saja, ini adalah tipe datetime (lebih lanjut tentang pilihan jenis kemudian). Rekaman aktif menangani bidang ini sepanjang hidup catatan Anda, pengaturan dan memperbarui mereka saat yang tepat.

Kolom keenam dan terakhir adalah id, yang tidak tercantum di sini karena itu ditambahkan secara default. Itu adalah unik primary key untuk tabel.

Membuat tabel adalah hanya satu digunakan untuk class migrasi; mereka metode Anda mengutak-atik database, ingat, sehingga mereka dapat melakukan pekerjaan database Anda mungkin pernah perlu lakukan. Tapi salah satu ide-ide penting dengan migrasi adalah bahwa Anda dapat menggulung mereka kembali, atau membatalkan efek mereka. Ini berarti bahwa setiap class migrasi harus memiliki informasi yang cukup untuk membatalkan dampaknya. Beberapa metode dapat "membatalkan diri"; sebagai contoh, berlawanan dengan menambahkan tabel adalah menghapus itu, yang tidak mengambil informasi tambahan. Inilah sebabnya mengapa kita dapat menggunakan metode perubahan di sini. Namun, jika kita melakukan sesuatu yang tidak dapat dibatalkan secara otomatis, kita harus menentukan tindakan untuk melakukan dan membatalkan migrasi kami. Dalam kasus ini, kami class migrasi harus memiliki dua metode: naik dan turun. Metode up akan detail apa yang harus dilakukan ketika menjalankan migrasi, dan metode bawah akan menjelaskan bagaimana untuk memutar kembali migrasi.

Mari kita menulis migrasi kita sendiri dari awal untuk memberikan fitur rollback ini mencoba. Kita mulai dengan menghasilkan migrasi kosong:

(Biasanya, Anda akan memberikan migrasi masuk akal nama.)

Sekarang, kita dapat membuka db/migrasi/<timestamp>_do_stuff.rb. Itu akan memiliki up/down metode secara default, tetapi melakukan maju dan mengganti bahwa dengan satu mengubah metode.</timestamp>

Kita mulai dengan membuat sebuah tabel yang tidak berguna, dengan sintaks mirip ke meja orang-orang kami di atas. Kemudian, kita menggunakan add_column metode untuk menambahkan kolom tabel orang: khususnya, pekerjaan kolom tipe string. Kedua tindakan ini dengan mudah dapat dibatalkan, dengan menjatuhkan tabel dan menghapus kolom.

Sekarang, mari kita jalankan migrasi kami dua. Kami melakukan ini melalui tugas rake:

Anda akan melihat output seperti ini:

Anda dapat melihat dari output persis apa yang telah dilakukan. Migrasi pertama menciptakan tabel orang; kedua menciptakan apa-apa meja dan menambahkan kolom. Sekarang, mari kita membatalkan migrasi terakhir kami berlari. Kita dapat melakukannya dengan menjalankan berikut:

Sekali lagi, output menegaskan:

Dan sekarang, migrasi kami tulis dari awal telah dibatalkan.

Catatan penting di sini: jika Anda relatif baru untuk Rails, Anda mungkin lupa bahwa migrasi tidak dijalankan secara otomatis bila Anda membuat model baru. Anda harus menjalankan secara manual. Ya, saya sudah lupa ini adil kali, dan bertanya-tanya apa yang terjadi, hanya untuk menyadari bahwa saya mencoba untuk bekerja dengan tabel bahkan tidak ada lagi.

Selain create_table dan add_column, ada banyak metode lain yang dapat Anda gunakan dalam file migrasi Anda. Kami tidak bisa masuk ke mereka semua dalam tutorial ini, tetapi jika mereka terlihat seperti sesuatu yang Anda perlukan, check out docs migrasi.

  • add_column
  • add_index
  • add_timestamps
  • change_column
  • change_table
  • create_table
  • drop_table
  • remove_column
  • remove_index
  • remove_timestamps
  • rename_column
  • rename_index
  • rename_table

Terakhir catatan pada migrasi: di sini adalah daftar jenis yang dapat Anda gunakan dalam kelas migrasi Anda:

  • biner
  • Boolean
  • tanggal
  • datetime
  • desimal
  • mengambang
  • bilangan bulat
  • primary_key
  • string
  • teks
  • waktu
  • timestamp

Memandang kelas Active Record

Sekarang bahwa kita telah menyiapkan database, kami siap melihat bagian lain dari model kita: kelas Active Record. Ini adalah bagian yang Anda akan benar-benar berinteraksi dengan dari controller Rails Anda. Ketika kita menciptakan model orang, file app/models/person.rb diciptakan; tampak seperti ini:

Jika Anda telah bekerja dengan Ruby sebelum, Anda mungkin akrab dengan metode attr_accessor, yang membuat metode pengambil dan penyetel untuk atribut yang bersangkutan. Yah, attr_accessible metode berbeda; Hal ini benar-benar rel-spesifik. Setiap properti yang attr_accessible-ized dapat diatur melalui penetapan massa. Ini hanya berarti menetapkan sekelompok properti pada objek sekaligus; Hal ini sering dilakukan ketika membuat objek, seperti:

Masing-masing properti yang didefinisikan dengan attr_accessible harus salah satu bidang kita didefinisikan dalam tabel database kami, dalam migrasi kami (ada beberapa pengecualian untuk ini). Tapi ini tidak berarti bahwa semua properti kami harus didefinisikan sebagai diakses; mungkin ada beberapa properti yang ingin Anda diatur lebih sengaja; sebagai contoh, properti admin yang memberikan hak administrasi untuk catatan pengguna mungkin tidak boleh dalam tugas massa, mana bisa mengatur sengaja / jahat.

Untuk kelas Active Record sederhana, hanya garis properti attr_accessible akan cukup. Ada sebenarnya banyak lagi kita dapat menambahkan kelas model kami untuk membuatnya lebih kuat, tapi pertama-tama mari kita orang ini pulang-pergi model, dan Lihat cara membuat instance model.


Membuat catatan

Dalam "Normal hari dalam kehidupan Rails app," semua catatan database akan dibuat di controller. Namun, kita akan menggunakan konsol Rails dalam tutorial ini. Di terminal, Anda dapat membuka konsol Rails dengan menjalankan salah satu dari berikut:

Ini akan membuka konsol Ruby di mana Anda dapat menggunakan semua kelas Model Anda.

Seperti yang Anda lihat di atas, kita dapat membuat baru catatan database dengan membuat sebuah kelas misalnya:

Baris kedua adalah nilai kami p: variabel objek orang baru. Perhatikan bahwa tiga dari enam properti telah ditetapkan, sementara yang lain tiga belum. Mereka akan menetapkan ketika record disimpan ke database, yang saat ini tidak (jika Anda mengetik keluar sekarang, tidak akan disimpan di database). Anda dapat mengkonfirmasi bahwa itu tidak disimpan dengan menjalankan

Untuk menyimpan catatan ke database, Anda dapat menyimpan metode:

Perhatikan bagian ini output:

Ya, itu adalah pernyataan SQL. Ingat, Active Record menggunakan database API di bawahnya, sehingga SQL masih perlu dijalankan. Itu adalah salah satu fitur dari konsol Rails: Anda dapat melakukan percobaan dengan metode Active Record yang berbeda dan melihat persis bagaimana mereka sedang menyentuh database. Ini akan membantu ketika Anda menjalankan metode yang menarik banyak data, mungkin dari beberapa tabel: Anda dapat memilih metode yang tepat untuk mendapatkan query SQL yang paling efisien.

Tapi sekarang, memeriksa catatan kami

Id, created_at, dan updated_at bidang telah ditetapkan.

Jika Anda ingin, Anda dapat membuat dan menyimpan catatan baru sekaligus, dengan cara membuat:

Ketika bekerja dengan individu catatan, Anda dapat menetapkan atau mengubah properti apapun dengan menggunakan metode mereka individu; hanya ingat bahwa properti tidak menyimpannya ke database; yang membutuhkan menyimpan panggilan.

Jika Anda ingin memperbarui beberapa atribut pada suatu waktu, Anda dapat menggunakan update_attributes, yang mengambil hash semua atribut yang Anda ingin mengubah:

Perbedaan yang penting tentang update_attributes adalah bahwa menyimpan dijalankan dalam metode; tidak perlu untuk menyimpan perubahan Anda sendiri.

Seperti saya katakan, meskipun, masih ada lagi yang bisa kita lakukan di kelas model. Jadi mari kita kembali dan melihat beberapa fitur-fitur lainnya.


Validasi

Validasi adalah bagian penting dari aplikasi web; ini adalah tempat kami memastikan bahwa data yang kami menempatkan ke dalam database bersih dan benar.

Sebelum kita mulai, penting untuk menyadari bahwa aturan validasi dibuat dalam kelas model Anda tidak mengubah database benar-benar. Misalnya, mengatakan properti tertentu diperlukan dalam model kelas tidak membuatnya diperlukan di database tingkat (seperti itu Anda akan mengatur di Anda-menunggu untuk itu — migrasi). Ini tidak benar-benar sesuatu yang Anda perlu khawatir tentang, saya hanya ingin memastikan bahwa Anda memahami gambaran besar di sini.

Jadi. Validasi. Dalam versi terbaru dari rel, kita menggunakan memvalidasi metode untuk mengatur semua validasi kami (itu adalah sebaliknya di masa lalu). Pertama, kami melewati itu bidang atau bidang kami adalah memvalidasi. Kemudian, kami dapat melewati itu hash akan sifat validasi. Ada sekelompok penolong validasi ini (sebagaimana mereka disebut) kita dapat menggunakan; Berikut adalah beberapa yang akan Anda gunakan sepanjang waktu.

Mungkin yang paling umum adalah hanya memvalidasi bahwa bidang tertentu telah diisi; untuk ini, kita melakukan validasi kehadiran:

Di sini, kami telah memvalidasi pada atribut first_name dan last_name. Di hash properti validasi kami, kami menetapkan kehadiran ke benar, yang berarti bahwa atribut tersebut tidak boleh ditinggalkan nol ketika record telah disimpan.

Validasi umum lain adalah memastikan sebuah field unik. Kita dapat melakukan ini dengan keunikan penolong.

Beberapa pembantu validasi tidak hanya mengambil true atau false; mereka membutuhkan beberapa pilihan. Sebenarnya, keunikan penolong adalah salah satu dari mereka; Ketika kita hanya set ke true, seperti di atas, sensitivitas kasus adalah pada. Benar-benar, meskipun, dengan nama pengguna, bob dan BOB harus sama. Jadi, kita harus melakukan ini:

Sekarang, bob dan BOB akan dianggap sama.

Kadang-kadang Anda akan ingin properti untuk menjadi salah satu dari serangkaian diberikan pilihan. Cobalah inklusi, yang membawa sebuah array (atau objek lain enumerable).

Kebalikan dari inklusi adalah pengecualian, yang akan memastikan nilai bidang ini tidak di set tertentu:

Jika Anda ingin memastikan bahwa bidang adalah panjang tertentu? Masukkan panjang. Ada banyak cara untuk menggunakan satu ini. Berikut adalah beberapa contoh:

Anda bahkan dapat mengatur batas:

Anda mungkin ingin memastikan bahwa nilai adalah sejumlah. Untuk ini, menggunakan numericality:

numericality juga dapat menangani kebijakan "tidak desimal":

Yang terakhir saya akan menunjukkan Anda adalah format, yang Mari kita tetapkan ekspresi reguler untuk bidang yang sesuai:

Ada beberapa orang lain, tetapi yang akan membantu Anda memulai. Sebuah berita menarik yang terakhir: Anda dapat membuat Anda sendiri validasi kelas pembantu. Periksa dokumentasi untuk lebih jelasnya.

Ada beberapa pilihan umum yang pergi dengan hampir semua pembantu validasi. Pertama, kita dapat mengatur allow_nil untuk, Yah, memungkinkan sebuah properti harus terisi.

Jika sebuah string kosong dapat diterima, Anda dapat menggunakan allow_blank sebagai gantinya.

Yang lebih umum adalah pesan; Jika validasi gagal, pesan akan dilampirkan ke objek (lebih lanjut tentang ini nanti). Tentu saja, semua pembantu validasi memiliki pesan default, tetapi Anda dapat mengatur sendiri dengan pesan.

Yang terakhir saya akan menyebutkan, yang memutuskan pada kondisi apa validasi akan dijalankan. Nilai-nilai: membuat (validasi hanya dijalankan ketika menyimpan catatan baru). : update (itu hanya dijalankan ketika menyimpan sebelumnya disimpan catatan), atau: Simpan (dijalankan dalam kedua kasus). Tentu saja, itu default: Simpan.


Kesalahan validasi

Instance model di Simpan metode mengembalikan true jika itu berhasil disimpan dan false jika tidak. Jika Anda mendapatkan salah kembali, Anda akan ingin tahu apa kesalahan adalah, benar?

Contoh Anda memiliki sebuah properti kesalahan, yang adalah ActiveModel::Errors instance. Setelah validasi menjalankan, objek ini diisi dengan semua pesan kesalahan untuk validasi gagal; ini disimpan dalam proptery pesan sendiri. Mengamati:

Biasanya, Anda akan ingin menampilkan kesalahan ini kepada pengguna, mungkin di bentuk yang mereka disampaikan. Salah satu cara termudah untuk melakukannya adalah untuk mengulang melalui properti full_messages dari dalam blok form_for Anda, dan mencetaknya di daftar atau sesuatu. Lebih mudah untuk membiarkan rel yang menangani semua markup yang dengan menjalankan form.error_messages.


Callback

Callback merupakan bagian dingin lain dari rekaman aktif; mereka membiarkan Anda menjalankan metode kustom pada diberikan kali. Jika Anda membaca Ribbit bangunan saya dalam Rails tutorial, Anda mungkin ingat bahwa kami digunakan before_save callback untuk mengatur properti avatar_hash pada pengguna sebelum menyimpannya. Pertama kita membuat metode kami ingin menjalankan:

Dan kemudian kami hanya mendaftar callback:

Ini berarti bahwa ketika kita memanggil Simpan, metode kami akan berjalan sebelum menyimpan sebenarnya dilakukan.

Kami juga menggunakan before_validation callback untuk strip dan downcase alamat email. Sementara ini hanya dua dari callback yang dapat Anda gunakan, mereka Kuasai contoh callback ini dapat berguna. Berikut adalah yang lain:

  • before_validation / after_validation
  • before_save / around_save / after_save
  • before_create / around_create / after_create
  • before_update / around_update / after_update
  • before_destroy / around_destroy / after_destroy

Bertanya-tanya tentang around_ * callback? Ini keren. Mereka dipanggil sebelum dilakukan tindakan, tapi kemudian Anda dapat melakukan tindakan dari dalam metode oleh hasil panggilan. Setelah tindakan selesai, reset metode panggilan balik dijalankan. Keren, ya?


Asosiasi

Database relasional yang paling akan memiliki beberapa tabel yang terkait dalam beberapa cara, sehingga hanya alami rekaman aktif yang akan mampu menangani hal ini: ia melakukannya melalui aktif catatan asosiasi. Katakanlah kita ingin memiliki rangka tabel dalam database kami, dan bahwa setiap orang dapat memiliki beberapa perintah. Bagaimana mendapatkan ini menyiapkan?

Kita harus mulai dengan membuat model pesanan kami:

Yang penting di sini adalah bidang person_id; seperti yang Anda duga, ini akan menjadi kunci asing kami, hubungan antara dua kelas. Kami menyebutnya person_id karena, setelah kami memberitahukan kelas model kami tentang hubungan, kelas Order akan mencari lapangan dengan nama itu secara default. Jika kita ingin menyebutnya sesuatu yang lain, seperti orderer_identifier, kita akan memiliki untuk memberitahu urutan bahwa bidang tidak bernama setelah kelas itu yang terhubung ke. Lebih mudah untuk pergi dengan default.

Migrasi yang dibuat oleh perintah ini akan segala sesuatu yang kita butuhkan, jadi saya akan bermigrasi sekarang:

Sekarang, kita perlu menginformasikan kelas tentang hubungan. Di dalam app/model/person.rb, tambahkan baris ini:

Sekarang, dalam app/model/order.rb, menambahkan ini:

Secara pribadi, kami katakan ada banyak pesanan untuk setiap record orang; menempatkan berbeda, setiap orang has_many memerintahkan. Sebaliknya, setiap urutan belongs_to contoh orang. Ini hanya menambahkan beberapa metode yang berguna untuk kasus kami orang dan ketertiban, yang kita akan lihat dalam sedikit.

Jadi, mari kita uji hubungan ini, akan kita? Di konsol Rails:

Garis yang menarik di sini adalah 3 dan 5. Kita bisa melakukan o.person_id = p.id, tapi karena kami penambahan kelas model, o.person = p adalah cara yang lebih pendek untuk melakukan hal yang sama. Kemudian, jalur 5: ini adalah salah satu dari metode tersebut ditambahkan: mengembalikan array dari semua pesanan yang memiliki orang kami. Berguna, tidak?

Ini adalah ringkasan yang baik dari jenis hal-hal yang dapat Anda lakukan dengan Active Record Asosiasi; ada satu ton lebih, dan hal ini dapat mendapatkan cukup rumit. Periksa dokumentasi Asosiasi semua kebaikan.


Memilih catatan

Selama ini kami telah telah membangun kelas Active Record atau menciptakan model catatan. Namun, sebagian besar bekerja dengan kelas Active Record semakin mereka catatan kembali. Seperti yang Anda duga, ada metode selusin yang dapat kita gunakan.

Pertama, dan paling sederhana, adalah metode yang mengembalikan semua catatan:

Semua metode ini mengembalikan array dari semua catatan.

Ada juga menemukan, yang membutuhkan id sebagai parameter, dan kembali dengan catatan id; itu juga bisa menerima array id dan kembali catatan yang cocok:

Jika Anda hanya ingin catatan pertama atau terakhir dalam koleksi, ada metode khusus untuk itu:

Salah satu fitur keren rekaman aktif adalah metode find kustom; di bawahnya, ini adalah hanya menggunakan method_missing, tetapi dari atas tampak seperti sihir murni. Berikut adalah cara kerjanya: menggunakan find_by_ nama metode<property> dan lulus nilai properti itu sebagai parameter. Sebagai contoh:</property>

Anda bahkan dapat rantai properti; perintah ini akan kembali rekaman yang sama:

Jika Anda melihat query SQL untuk terakhir dua metode, Anda akan melihat bahwa kita hanya sedang kembali hasil pertama (batas 1). Untuk menemukan semua catatan yang cocok, menggunakan awalan find_all_by sebagai gantinya. Jadi:

Akan lebih baik: Anda dapat menggunakan awalan find_or_create_by untuk membuat data jika tidak ada yang cocok ditemukan:

Ya, ini benar-benar bekerja. Namun, menyadari bahwa jika tidak ada catatan ditemukan, ini adalah seperti berjalan Person.create, yang menjalankan validasi. Jadi, misalnya, karena last_name dan usia yang diperlukan, ini akan mengakibatkan catatan yang tidak selamat akan atttached kesalahan:

Jika Anda tidak ingin catatan baru untuk diselamatkan segera, menggunakan awalan find_or_initialize_by.

Ada beberapa metode lain Anda mungkin menemukan berguna ketika memilih catatan. Yang benar-benar berguna adalah mana yang mengambil mana klausa dari pernyataan SQL.

Jika Anda mengambil nilai dari pengguna untuk digunakan di mana, Anda tidak boleh melakukan interpolasi mereka, karena takut SQL Injeksi. Anda harus menggunakan tanda tanya di tempat mereka, dan kemudian melewati nilai sebagai parameter lain:

... atau sesuatu yang serupa.

Semua metode ini kita telah melihat begitu jauh kembali semua bidang catatan kembali. Anda dapat menggunakan metode pilih sebelum mereka hanya mengembalikan instance model dengan beberapa properti yang dipilih:

Kegiatan pernyataan SQL yang umum termasuk membatasi dan offsetting; kasus penggunaan besar untuk ini adalah paging hasil. Limit dan offset metode mengambil satu nomor parameter masing-masing. Jika Anda menggunakan mereka sendiri, mereka bekerja pada seluruh koleksi; sebagai contoh, ini mengembalikan lima catatan, melompat-lompat dua yang pertama:

Tetapi Anda dapat memilih catatan ke limit dan offset dengan salah satu fungsi lain:

Ada beberapa metode permintaan lain, tetapi kita telah membahas yang Anda akan menggunakan 90% dari waktu.

Jika Anda melakukan kompleks pertanyaan seperti ini, itu akan menjadi ide yang baik untuk menciptakan metode permintaan kelas Anda sendiri, dalam model Anda. Katakanlah kita membiarkan orang-orang yang mencari pengguna lain dengan nama terakhir mereka, dan kami halaman hasil dengan 10 pengguna per halaman. Query mungkin terlihat seperti ini:

Selain ini menjadi agak panjang untuk controller, offset yang harus berubah untuk setiap halaman; 0 hanya bekerja untuk halaman pertama. Jadi, kita menulis sebuah metode dalam kelas orang kami:

Ini kembali set yang kita inginkan, dan kita dapat memilih halaman yang dan berapa banyak hasil per halaman kami ingin (atau meninggalkan mereka untuk default mereka masuk akal. Dan bahkan lebih baik, ini adalah metode rapi yang bagus yang kita dapat memanggil dari controller kami seperti ini:

Untuk lebih lanjut tentang query, periksa Active Record query dokumentasi.


Kesimpulan

Jika Anda hanya mendapatkan ke rel, Anda hanya belajar hampir segala sesuatu yang Anda perlu tahu tentang rekaman aktif untuk sementara waktu. Tentu saja, seperti setiap bagian lain dari rel, Active Record mendalam dan kaya; ada banyak potongan-potongan yang saya tidak disebutkan dalam tutorial ini. Untuk lebih lanjut tentang mereka, lihatlah panduan rel untuk model. Terima kasih untuk membaca!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.