Knex: Benih satu file!

+1 @tgriesser @bendrucker

:+1:

+1

:+1: Ini sangat berguna untuk tes.

Harus punya!

:+1: Saya bergabung untuk meminta. Akan sangat nyaman untuk tes!

saya mendukung permintaan ini. di laravel Anda dapat dengan mudah melakukan ini:
php artisan db:seed --class=UsersTableSeeder

👍 Sangat relevan dan akan sangat berguna!

Fitur yang sangat dibutuhkan :) 👍

Sebagai solusinya, Anda sudah dapat menyemai file tunggal hanya dengan menulis skrip simpul yang melakukan penyemaian dan menjalankannya secara langsung:

const knexConf = require('./knexfile');
const knex = require('knex')(knexConf);

// insert anything you like...

Saya tidak melihat banyak manfaat memiliki file seed terpisah. Untuk menjalankan tes, membuat skema populasi khusus yang terpisah jauh lebih fleksibel dan cepat daripada menggunakan sistem file knex client + seed.

menambahkan tabel setelah aplikasi masuk ke produksi dan menyemai itu adalah kasus penggunaan saya yang sebenarnya

@asequeir-public Anda harus menggunakan migrasi untuk itu.

Saya memulai proyek baru untuk menyemai tabel dengan knex.js, di sini. Bantuan apa pun akan menyenangkan!

@asequeir-public Anda harus menggunakan migrasi untuk itu.

Untuk skema dan perubahan pada data yang ada sebagai akibat dari perubahan skema tentu saja, tetapi untuk data baru (terutama dalam jumlah besar) bisa sangat bermasalah dalam migrasi. Tampaknya menjadi konsensus umum di seluruh kerangka kerja, berbicara dengan rekan-rekan googling sedikit, bahwa migrasi tetap bebas dari data jika memungkinkan.

tetapi untuk data baru (terutama dalam jumlah besar)

Nah jika itu adalah data statis untuk diisi ke setiap DB (misalnya informasi tentang kategori, yang sama untuk setiap instalasi, dll.), migrasi adalah tempat yang tepat untuk melakukannya.

Kalau tidak, itu tergantung pada data. Skrip yang terisi tidak baik untuk menambahkan sejumlah besar data yang hanya cocok untuk database tunggal dan tidak untuk instalasi/pengaturan pengujian lainnya.

Jika data satu kali ditambahkan ke produksi, itu harus dilakukan dengan skrip apa pun, yang mendorong data ke tempatnya. Setelah itu harus dipulihkan dari cadangan DB, karena menerapkannya lagi akan merusak segalanya.

Saya lebih suka memiliki fitur, yang akan menghapus seluruh sistem skrip yang terisi dari knex dan mungkin menambahkan paket eksternal untuk orang-orang yang suka memilikinya (mereka tidak mengimplementasikan fungsionalitas apa pun yang tidak akan sepele untuk diterapkan dengan skrip node.js sederhana seperti yang disebutkan dalam komentar https://github.com/tgriesser/knex/issues/801#issuecomment-355494104).

Nah jika itu adalah data statis untuk diisi ke setiap DB (misalnya informasi tentang kategori, yang sama untuk setiap instalasi, dll.), migrasi adalah tempat yang tepat untuk melakukannya.

Saya juga tidak setuju dengan ini. Itulah gunanya benih, bukan migrasi. Migrasi hanya dimaksudkan untuk mengubah struktur database, bukan datanya. Di atas semua itu, migrasi seharusnya bersifat sementara, dan dapat dihapus setelah mereka mencapai tujuan yang bermanfaat. Jika mereka berisi data ini tidak akan mungkin.

@ricardograca Secara teoritis, ya. Secara praktis, migrasi adalah cara terbaik untuk memastikan bahwa Anda memiliki kumpulan data yang konsisten di berbagai lingkungan. Dan saya tidak setuju bahwa "transaksi dapat dihapus", biasanya Anda ingin menyimpannya selamanya sehingga Anda selalu dapat membuat ulang lingkungan dari awal (setidaknya bagian yang tidak bergantung pada input eksternal).

@pmead Apa yang biasanya kami lakukan dalam produksi dengan kumpulan data besar adalah menggunakan migrasi untuk memanggil importir dan menyimpan data aktual dalam file CSV yang mungkin atau mungkin tidak disimpan dalam repo (berdasarkan berapa banyak nilai tahan lama yang mereka miliki dan ukurannya)

...biasanya Anda ingin menyimpannya selamanya sehingga Anda selalu dapat membuat ulang lingkungan dari awal (setidaknya bagian yang tidak bergantung pada input eksternal).

Tidak juga. Anda hanya ingin menyimpannya selamanya sekarang karena tidak ada sistem yang lebih baik untuk membuat ulang skema dari awal dengan Knex, seperti fungsionalitas file skema dari Rails. Namun meskipun demikian, setelah semua mesin yang menjalankan kode Anda diperbarui ke versi skema terbaru, Anda dapat menghapus semua migrasi dengan aman dan membuat yang baru berdasarkan status saat ini yang akan menggantikan migrasi awal. Jika Anda mengerjakan proyek besar, Anda akan berakhir dengan ratusan atau bahkan ribuan migrasi jika Anda tidak membersihkannya dari waktu ke waktu.

Sangat sia-sia jika harus menjalankan banyak migrasi pada mesin baru tempat Anda menerapkan kode Anda (atau setiap kali menjalankan pengujian). Dalam hal ini Anda mungkin tidak ingin melalui semua riwayat perubahan migrasi hanya agar Anda dapat mencapai status terbaru, Anda hanya menginginkan status terbaru.

Salah satu kasus penggunaan khusus di mana skrip populasi berguna adalah ketika Anda ingin kumpulan data di-refresh tetapi itu tidak cukup sering terjadi untuk menjamin metode lain, misalnya, impor data tahunan.

Migrasi pada saat itu terasa agak rumit karena untuk beberapa lingkungan mereka sudah berjalan yang berarti Anda akan memerlukan migrasi baru dan tidak bisa begitu saja mengubah CSV (yang menurut saya akan terjadi dalam apa yang Anda sebutkan @kibertoad ?) dan lingkungan baru akhirnya tidak perlu memuat kumpulan data yang berpotensi besar lagi dan lagi.

Saya juga berpikir pemisahan skema -> migrasi, data -> skrip seed/populate adalah pemisahan masalah yang lebih baik dan tidak terlalu mengejutkan dalam proyek besar.

Menariknya @ricardograca Rails juga merupakan paradigma yang secara mental saya

Hanya untuk memulai dengan dukungan benih yang sebenarnya, saya ingin mengatakan dengan jelas:

Memiliki dukungan untuk benih di knex tidak membantu apa pun dengan poin apa pun yang dibahas dalam balasan ini

Sekarang, kita dapat melanjutkan diskusi filosofis tentang migrasi dan hal-hal skema :)

Saya juga tidak setuju dengan ini. Itulah gunanya benih, bukan migrasi. Migrasi hanya dimaksudkan untuk mengubah struktur database, bukan datanya. Di atas semua itu, migrasi seharusnya bersifat sementara, dan dapat dihapus setelah mereka mencapai tujuan yang bermanfaat. Jika mereka berisi data ini tidak akan mungkin.

Kedengarannya benar-benar rel-centric dan pandangan purifist ke subjek. Saya ingin mendengar alasan sebenarnya mengapa migrasi harus dapat dibuang setelah digunakan dan mengapa mereka tidak boleh berisi data apa pun.

Jika satu-satunya alasan adalah akumulasi ribuan file migrasi dapat dicegah juga dengan dump basis data knex dan awal / tengah (saya memiliki alat yang sangat bagus untuk itu di proyek saya sendiri untuk berbagai tujuan).

Anda dapat membuangnya ketika mereka telah memenuhi tujuannya (misalnya ketika dump database awal baru dibuat dengan semua data awal yang diperlukan). Biasanya orang merasa lebih mudah untuk menyimpan migrasi dalam repo.

Tidak juga. Anda hanya ingin menyimpannya selamanya sekarang karena tidak ada sistem yang lebih baik untuk membuat ulang skema dari awal dengan Knex, seperti fungsionalitas file skema dari Rails.

Knex tidak dapat beradaptasi seperti itu dalam waktu yang lama + bahkan file skema Rails sangat terbatas dengan fitur SQL yang didukungnya. Knex tidak akan pernah menjadi Rails (tetapi pada akhirnya mungkin mendapatkan sesuatu seperti file skema yang didukung).

Sangat sia-sia jika harus menjalankan banyak migrasi pada mesin baru tempat Anda menerapkan kode Anda (atau setiap kali menjalankan pengujian). Dalam hal ini Anda mungkin tidak ingin melalui semua riwayat perubahan migrasi hanya agar Anda dapat mencapai status terbaru, Anda hanya menginginkan status terbaru.

Ya, dengan dump basis data knex sangat berguna, dengan proyek yang lebih besar dan untuk pengujian untuk mengatur ulang skema + data awal terbaru. Saya tahu akan menyenangkan untuk menawarkan perkakas yang lebih baik dan beberapa praktik terbaik untuk itu.

@pmead

Saya juga berpikir pemisahan skema -> migrasi, data -> skrip seed/populate adalah pemisahan masalah yang lebih baik dan tidak terlalu mengejutkan dalam proyek besar.

Itu tidak bekerja dengan baik di kehidupan nyata dan Anda dapat dengan mudah memiliki direktori yang penuh dengan skrip populasi basis data tanpa ada seed yang membungkusnya. Kemudian Anda cukup memanggil node seeds/refresh-yearly.js dan data Anda terisi.

Menariknya @ricardograca Rails juga merupakan paradigma yang secara mental saya

Ya, Rails adalah pengaturan yang sangat berbeda dan catatan aktif adalah alat tingkat yang jauh lebih tinggi daripada knex. Tentu kita juga bisa belajar dari sana.

Saya ingin mendengar alasan sebenarnya mengapa migrasi harus dapat dibuang setelah digunakan dan mengapa mereka tidak boleh berisi data apa pun.

Yah, ini terutama masalah saat menyiapkan mesin baru. Misalnya, mengapa Anda ingin melalui semua proses membuat kolom, memodifikasinya, memodifikasinya lagi, dan lagi lalu menghapusnya? Ini akan terjadi jika Anda memiliki semua migrasi dan itu tidak masuk akal. Ini hanya sebuah contoh, hal yang sama akan terjadi dengan tabel, dan proyek besar dapat dengan mudah mengakumulasi banyak perubahan kecil. Dalam pikiran saya, tidak masuk akal untuk menelusuri seluruh sejarah perubahan, itu sebabnya migrasi harus bersifat sementara. Perhatikan bahwa ini juga berlaku untuk rangkaian pengujian saat menggunakan Knex, di mana seluruh daftar migrasi dijalankan di antara setiap pengujian, yang memperlambat proses.

Satu-satunya keuntungan yang dapat saya pikirkan tentang menjaga migrasi selamanya adalah Anda dapat kembali ke masa lalu ke komit yang lebih lama dan membangun kembali database seperti pada saat itu. Anda harus menghapus semua tabel sebelum mencobanya, jadi kegunaannya masih bisa diperdebatkan.

Semua masalah ini akan diselesaikan dengan fungsionalitas seperti "file skema". Dan BTW, batasan yang disebutkan dalam Rails benar, tetapi juga dapat menghasilkan file sql yang tidak memiliki batasan seperti itu dan file tersebut dapat digunakan dengan alat pembuatan skema terintegrasi, jadi tidak perlu dijalankan skrip tambahan atau apa pun. Saya tahu ini tidak terkait dengan fitur ini, jadi saya bahkan tidak yakin mengapa kami membahas ini di sini :sweat_smile:

Intinya adalah saya pikir permintaan fitur ini valid, dan bahkan jika Anda lebih suka menggunakan migrasi untuk memasukkan data ke dalam database, saya tidak melihat konflik dengan apa yang diminta.

tidak masuk akal untuk menelusuri seluruh sejarah perubahan, itu sebabnya migrasi harus bersifat sementara. Perhatikan bahwa ini juga berlaku untuk rangkaian pengujian saat menggunakan Knex, di mana seluruh daftar migrasi dijalankan di antara setiap pengujian, yang memperlambat proses.

Tidak perlu menjalankan migrasi sebelum setiap pengujian, sekali untuk setiap rangkaian pengujian sudah cukup dan setelah itu memotong data + memasukkan data baru sudah cukup. Menjalankan/mengembalikan migrasi sebelum setiap pengujian adalah praktik yang buruk. Juga dump SQL awal yang dimuat ke DB sebelum menjalankan tes menghilangkan kebutuhan untuk itu.

Intinya adalah saya pikir permintaan fitur ini valid, dan bahkan jika Anda lebih suka menggunakan migrasi untuk memasukkan data ke dalam database, saya tidak melihat konflik dengan apa yang diminta.

Seperti disebutkan di utas ini sudah beberapa kali, seseorang tidak melakukan seed sistem file untuk itu sama sekali karena mudah untuk menginisialisasi instance knex baru dari skrip node.js sederhana daripada menulisnya dalam format seed-file. File seed hanya menambah kerumitan yang tidak perlu.

Ada paradigma di mana Anda tidak ingin mempertahankan status DB yang konsisten di seluruh lingkungan Anda. Pengujian A/B adalah salah satu contohnya. Memisahkan skema DB dari data DB menambah fleksibilitas tambahan.

Diskusi berjalan melingkar. Mengunci diskusi lebih lanjut.

Jika seseorang ingin memberikan dukungan bagaimana seed dijalankan melalui knex client pull request dipersilahkan.

Namun kita tidak boleh menambahkan dukungan untuk menyimpan informasi tentang benih mana yang telah dijalankan. Jika Anda perlu memverifikasi bahwa benih yang sama tidak dijalankan beberapa kali, Anda harus menggunakan migrasi sebagai gantinya.

Ini tidak meminta untuk menyimpan informasi tentang benih mana yang telah berjalan atau untuk memverifikasi bahwa benih yang sama tidak dijalankan beberapa kali. Itu hanya meminta kemampuan untuk menentukan satu file benih acak untuk dijalankan. Misalnya knex seed:run --grep=users .

@ricardograca Itu masuk akal. Bagaimana menurut Anda file benih dapat diidentifikasi? dengan nama file lengkap?

Saya pikir itu yang paling masuk akal ya. Namun, tidak yakin apakah fungsionalitas penuh seperti grep diperlukan, atau hanya sesuatu seperti --single=my_seed_file.js .

Glob telah menjadi alat paling umum yang saya lihat untuk mencocokkan beberapa atau satu nama file di dunia simpul.