Knex: Memodifikasi kolom

Daftar periksa:

• [x] Mengganti Nama Kolom
• [ ] Ubah Null
• [ ] Ubah Default
• [ ] Ubah Tipe Data

Dukungan untuk mengganti nama kolom sangat mendasar, tidak mendukung penggantian nama bidang yang merupakan kunci asing, misalnya, seperti yang saya laporkan di #157.

Diakui—lihat daftar periksa di pos Tim dua di atas milik Anda. Jika ini adalah prioritas Anda dan Anda membutuhkannya segera, kami akan sangat menghargai PR.

Kami membutuhkan fungsi ini juga untuk @lemonde CMS.

Menambahkan indeks atau mengubah enum harus dimungkinkan tanpa mengeksekusi kueri mentah.

@neoziro Saat ini Anda terbatas pada pengaturan kolom tertentu sebagai indeks. Modifikasi skema lainnya ada di daftar tugas, dan seperti biasa PR dihargai jika Anda sangat membutuhkan sesuatu.

Pada catatan lain, saya baru saja memulai utas untuk mengumpulkan kasus penggunaan unggulan untuk Knex/Rak Buku. Saya ingin mendengar bagaimana kalian menggunakan knex di @lemonde. Anda dapat berbagi di sini: #170.

@bendrucker Saya mengerti sepenuhnya sikap Anda dalam mengirimkan PR. Saya berharap untuk mencoba mengalihkan beberapa sumber daya Ghost untuk menyelesaikan ini, tetapi kami memiliki sumber daya yang sangat terbatas saat ini.

Melihat beberapa dari kita berharap untuk mendapatkan fitur ini, mungkin akan baik untuk mendapatkan beberapa pemikiran dari @bendrucker / @tgriesser tentang seperti apa seharusnya API (apakah saran saya di atas benar) dan mungkin brain dump pemikiran atau gagasan tentang bagaimana hal itu dapat dicapai / pendekatan yang disukai.

Saat ini, banyak ide/prinsip tentang bagaimana hal-hal bekerja dan harus bekerja di knex/rak buku masih (sejauh yang saya dapat temukan) di kepala @tgriesser ... Saya menyadari dia tidak memiliki pengalaman hebat banyak waktu, tapi mungkin halaman wiki yang penuh dengan tempat inspirasi untuk bit yang berbeda berasal, ide untuk masa depan, hal-hal cerdas yang ada di perpustakaan dan mengapa, semua info orang dalam sehingga kita semua bisa mengejar apa yang Anda lakukan berpikir, dan coba lanjutkan dengan cara yang Anda setujui :sunglasses:

Atau mungkin kamu bisa ngeblog semuanya.. di Ghost :wink:

Haha pasti... maaf @ErisDS dan semuanya... Saya benar-benar perlu mendedikasikan waktu untuk duduk dan menulis banyak hal yang masih ada di kepala saya. Semoga banyak hal termasuk semua hal di atas akan diselesaikan setelah saya mendapatkan lebih banyak konsistensi internal seputar pembuatan kueri di Knex, di mana saya dapat lebih fokus pada pengorganisasian fitur yang telah saya rencanakan untuk Rak Buku (model typecasting, soft deletes, a composite plugin kunci, dll).

Saya pikir itu juga akan sangat bagus untuk mendapatkan contoh aplikasi open source bersama-sama (selain hantu) yang menampilkan beberapa fitur yang berbeda dari knex/rak buku untuk dilihat orang-orang. Saya telah memulai klon berita peretas, tetapi belum punya waktu untuk menyelesaikannya... @bendrucker , @johanneslumpe , @tkellen atau siapa pun yang berminat membantu dengan hal seperti itu?

@tgriesser Saya sangat merekomendasikan hanya duduk dan memuntahkan apa pun yang terlintas dalam pikiran, daripada mencoba mengklarifikasi melalui kode. Pada titik tertentu, prinsip-prinsip jauh lebih mudah dikomunikasikan dengan kata-kata.

Saya pribadi merasa knex & rak buku menakutkan untuk berkontribusi, karena saya merasa saya tidak memiliki cukup info latar belakang atau panduan tentang cara terjebak - meskipun sangat bergantung pada perpustakaan ini dan mengetahuinya dengan cukup baik.

@ErisDS Saya menggunakan wiki untuk "hal-hal bodoh" :senyum:

@tgriesser Saya pasti akan membantu dengan aplikasi contoh OS

Perubahan besar mungkin harus menunggu refactors lain, tapi saya pikir itu layak mempertimbangkan refactor non-breaking dari skema builder API juga. Ada campuran aneh sekarang dari janji, fungsi sinkronisasi yang dapat dirantai, dan panggilan balik. Mungkin table.column(name) mengembalikan ChainableColumn dan kemudian semua jenis fungsi ( integer , text , dll.) melepaskannya.

Kemudian akan ada metode create , drop , rename untuk mengatur operasi kolom SQL yang sebenarnya ( ADD , ALTER , DROP ). create akan menjadi default.

Bagi saya itu lebih cocok dengan gaya Knex lainnya. Cukup hubungkan semua komponen kueri Anda dan biarkan keajaiban terjadi daripada berurusan dengan banyak sintaks seperti dropColumn et al.

@tgriesser Saya _mungkin_ dapat mengkloning berita peretas Knex/Rak Buku di BocoupFest pada bulan Februari (4-7). Mungkin @tbranyen dan saya bisa menyiapkannya. Saya akan memberi tahu Anda.

@tgriesser Tentu saja! Saya akan membantu di mana saya bisa!

dikirim dari iPhone saya

Pada 24 Januari 2014, pukul 17.25, Tyler Kellen [email protected] menulis:

@tgriesser Saya mungkin bisa mendapatkan klon berita peretas Knex/Bookshelf di BocoupFest pada Februari (4-7). Mungkin @tbranyen dan saya bisa menyiapkannya. Saya akan memberi tahu Anda.

—
Balas email ini secara langsung atau lihat di GitHub.

@tgriesser

Seperti yang telah disebutkan oleh @ErisDS oleh posting asli, saya pikir akan lebih baik jika saya bisa menjatuhkan atau mengganti nama kolom pada SQLite3 dengan fungsi migrasi knex.

lib/migration.js dan lib/cli/migrate.js tidak tahu klien apa yang mereka targetkan dan tindakan apa yang dilakukan pada waktu migrasi. Mereka menerapkan migrasi melalui fungsi pembuatan kueri knex. Tetapi untuk menerapkan penurunan atau penggantian nama kolom pada SQLite3, hanya ketika klien adalah SQLite3 dan tindakan yang dilakukan adalah mengganti nama atau menjatuhkan, kita harus membuat tabel untuk menyalin data, menyalin data dari tabel asli ke tabel untuk disalin , jatuhkan tabel asli, buat tabel baru, salin data ke tabel baru dan jatuhkan tabel untuk menyalin data.

Jika fungsi migrasi ini akan diimplementasikan, menurut Anda di mana hal-hal peralihan ini harus ditempatkan?

Catatan: saat ini di proyek saya, sebagai solusinya, saya mengganti nama (atau menjatuhkan) kolom dalam file migrasi sebagai berikut:

exports.up = function(knex, Promise) {
  if (require('config').database.client === 'mysql') {
    return knex.schema.table('posts', function(t) {
      t.renameColumn('foo', 'bar');
    });
  } else if (require('config').database.client === 'sqlite3') {
    // copy original table
    return knex.raw('create table copy_posts AS select * from posts')
      .then(function() {
        return knex.schema.dropTable('posts');
      })
      .then(function() {
        // create new posts table
        return knex.schema.createTable('posts', function(t) {
          // ...
          // other column definitions
          // ...
          t.string('bar');
        });
      })
      .then(function() {
        return knex.raw('insert into posts select * from copy_posts');
      })
      .then(function() {
        return knex.schema.dropTable('copy_posts');
      });
  }
};

Ya, menjatuhkan/mengubah akan menyenangkan. Pada dasarnya itu hanya sulit untuk diterapkan, dan karena hal-hal belum cukup konsisten secara internal, saya menunda, karena implementasi saat ini (saya cukup yakin kolom ganti nama berfungsi saat ini) adalah semacam peretasan besar.

Ini adalah versi baru renameColumn di cabang 0.6.0-wip mendatang:
https://github.com/tgriesser/knex/blob/6a2e3352a7cb9e6f989e7f572ef7ea1e363ef8e4/lib/clients/sqlite3/schema/tablecompiler.js#L81

Saya akan menggunakan kembali sebagian besar kode di sana juga dalam menjatuhkan kolom/mengubah tipe yang merupakan sesuatu yang saya tahu juga dicari oleh @ErisDS . Semoga rilis ini dilakukan dalam beberapa minggu mendatang.

@tgriesser

Terima kasih untuk balasan Anda.
Versi baru renameColumn Anda sangat bagus! :+1:

Saya menantikan rilis baru Anda.

Ini adalah berita bagus :+1:

Selain menonton masalah, apakah ada cara yang baik untuk mengikuti kemajuan? Peta jalan, milis, saluran irc atau semacamnya di mana semua kemajuan ini diatur? Saya sangat ingin mengikuti perkembangan & membantu jika memungkinkan.

Ya kalau mau mampir #bookshelf saya biasanya ada di sana (perlu mengiklankan saluran itu sedikit). Akan melihat peta jalan segera setelah perubahan besar dengan internal telah stabil.

Sepertinya menjatuhkan kolom kunci asing juga dimungkinkan saat ini .

Tidak yakin apakah dapat mengubah panjang kolom TEXT ada di radar sebagai bagian dari ini, jadi berikan catatan bahwa ini adalah sesuatu yang dibutuhkan Ghost.

Saya tahu bahwa 0,7 sedang dalam pengerjaan, apakah itu membuat kita lebih dekat ke 'internal yang stabil' yang merupakan prasyarat untuk mendapatkan dokumentasi 'kotoran pintar'? :menjulurkan lidah mengedip mata:

+1 untuk mengubah nol & bukan nol pada kolom

@tgriesser , @bendrucker : Apakah ada pembaruan pada fungsi ini? Menulis kueri mentah di setiap migrasi yang saya miliki yang memodifikasi kolom (hampir semuanya), menjadi sedikit membuat frustrasi.

Tidak, maaf

Apakah mungkin untuk memodifikasi metode renameColumn() (dan akhirnya metode modifikasi kolom lainnya) sehingga ia mengembalikan objek kolom yang dimodifikasi sehingga seseorang dapat mengaitkan salah satu metode kolom yang dapat dirantai ke sana? Yaitu saya mencoba memperbarui referensi setelah mengganti nama kolom:

table.renameColumn('stuff_id', 'some_stuff_id').references('some_stuff.id')

Ini menghasilkan kesalahan yang mengatakan bahwa:

Object #<TableBuilder_PG> has no method 'references'

Jika itu akan menjadi perubahan yang melanggar (sepertinya, meskipun saya tidak yakin apakah ada yang menggunakan objek pengembalian saat ini) maka setidaknya berikan cara untuk memilih kolom yang sudah ada.

Maaf karena secara efektif mengomel tentang masalah kuno - tetapi saya sangat ingin dapat mengubah panjang kolom teks. Saya akan sangat senang untuk ikut serta dan mencoba berkontribusi jika ada konsensus tentang apa yang seharusnya menjadi API?

Apakah masih mungkin untuk mengubah jenis kolom atau haruskah saya menggunakan .raw() ?

@olalonde Tidak, Anda harus menggunakan .raw() .

@ErisDS rencananya adalah membuat pembangun tidak dibatasi oleh pernyataan normal tetapi juga menambahkan api untuk mengubah tabel:

knex.alterTable(tableName).modifyColumn(colName, type)
knex.alterTable(tableName).drop(colName)

Saya juga sedang mengerjakan API untuk mendefinisikan apa struktur tabel untuk database _seharusnya_ sehingga Anda akhirnya dapat menggunakan objek ini untuk membandingkan dengan keadaan database saat ini (mirip dengan apa yang dilakukan ghost, tetapi sedikit lebih teruji/ ditentukan)

const {database, table, column} = require('knex').Schema

var db = database({name: 'tryghost'}, [
  table('posts', [
    column('id', 'int'),
    column('slug', 'string'),
  ])
])

knex.select(db.posts).where(db.posts.id, 1)

// SELECT posts.* FROM posts WHERE posts.id = 1

Bekerja untuk memindahkan beberapa hal untuk mendapatkan api yang lebih baik daripada harus menggunakan raw

Nullable ada tetapi tidak mungkin untuk memilih kolom yang ada seperti

t.column('existing_column').modifySomehow()

Tetapi tim Anda mengatakan bahwa Anda sedang mengerjakan ini.

Membaca dengan teliti kode sepertinya mungkin ada beberapa kemajuan ke arah ini? https://github.com/tgriesser/knex/blob/master/src/schema/columnbuilder.js#L71

Ada kemungkinan update? Di mana Anda berada dengan perubahan ini, apa yang bisa dilakukan untuk membantu?

Ada pembaruan dengan ini?

Sepertinya kita bisa menggunakan metode .alterTable atau apa?

Saya ingin melihat API seperti table.modifyColumn('myCol').notNullable().defaultTo('hello') .

Menabrak!

Saya sama tertariknya dengan siapa pun untuk melihat beberapa gerakan dalam masalah ini. Jika Anda setuju, dan ingin menginspirasi beberapa gerakan tentang masalah ini, hal terbaik yang harus dilakukan adalah meluangkan waktu untuk menjelaskan apa kasus penggunaan Anda dan mengapa Anda perlu knex untuk menambahkan dukungan. Bahkan mungkin menawarkan bantuan - dokumen & QA sama bergunanya dengan kode.

Menambahkan komentar tanpa konten sepertinya tidak akan menginspirasi perubahan apa pun dalam status quo di sini, bahkan menurut saya, kemungkinan besar orang yang ingin Anda dengar Anda menekan "berhenti berlangganan" pada masalah sebagai hasilnya.

Per saran @ErisDS , situasi saya adalah: Saya memiliki skema dengan tipe col string Saya ingin mengubah ke datetime . Saya terbuka untuk menjalankan proses di mana saya menghapus string col yang ada dan menambahkan yang baru dengan datetime , dan akan menghargai dokumentasi tentang cara melakukan ini.

@kuanb Ini adalah utas permintaan fitur - itu berarti tidak ada API khusus untuk melakukan ini. Saat ini Anda harus menggunakan metode schema.table lain untuk membuat kolom baru, menyalin data, lalu menghapus kolom asli. Jika Anda memerlukan bantuan lebih lanjut dengan ini, saya sarankan membuka masalah baru atau membuat pertanyaan StackOverflow.

@rhys-vdw mohon maaf atas kebingungan yang saya sebabkan. Maksud saya adalah memberikan "tanggapan" ke komentar @ErisDS bahwa kami harus menyertakan kasus penggunaan untuk menunjukkan perlunya hal seperti ini terjadi. Saya mengerti ini adalah permintaan fitur.

Saat ini saya dapat melakukan migrasi dengan baik menggunakan knex.raw( ... ) tetapi ingin menunjukkan bahwa saya berada dalam situasi di mana fitur seperti itu dari perpustakaan knex akan menyenangkan. Mungkin saya salah memahami `permintaan ErisDS.

Ah benar, saya hanya menanggapi "dan akan menghargai dokumentasi tentang cara melakukan ini.". Tanpa stres. :)

+1 untuk modifikasi tipe tanggal kolom

Pertanyaan jujur. Apakah abstraksi ini benar-benar melayani tujuan yang bermanfaat? Cukup tulis SQL.

Knex harus menjadi pembuat kueri, bukan sistem migrasi. Berikut adalah contoh sistem migrasi yang setidaknya masuk akal:

https://github.com/tkellen/node-postgres-ansible-api-boilerplate/blob/master/careen.js
https://github.com/tkellen/node-postgres-ansible-api-boilerplate/blob/master/package.json#L6 -L9
https://github.com/tkellen/node-postgres-ansible-api-boilerplate/tree/master/migrations

Mengapa saya harus menyentuh SQL? Bayangkan sebuah kasus jika suatu saat saya ingin beralih dari PostgreSQL ke MySQL. Berapa lama bagi saya untuk mempelajari semua gotcha di kedua sisi dan menulis ulang semua migrasi SQL mentah. Plus, jika ActiveRecord bisa melakukan migrasi dengan benar, mengapa Knex tidak bisa?

Beralih antara MySQL dan PostgreSQL dengan mulus adalah mimpi yang tidak akan pernah terjadi pada siapa pun dalam skala yang berarti. Semua sistem database memiliki kekuatan dan kelemahan. Sama sekali tidak masuk akal untuk membatasi diri Anda pada subset yang berfungsi di keduanya sehingga Anda dapat secara sewenang-wenang memutuskan untuk beralih di antara satu atau yang lain.

ActiveRecord tidak melakukan migrasi "benar". Ada banyak fungsi yang tidak menyediakan DSL. Anda benar bahwa lebih banyak upaya manusia telah dibuang ke dalam sistem migrasi ActiveRecord. Alasannya adalah angka sederhana.

Knex:

Rekaman Aktif:

Pertanyaan saya tetap. Di mana nilai dalam DSL ini? Apa pun yang ingin Anda migrasikan dapat diekspresikan dalam SQL. Anda tidak perlu membuat gula setengah matang di atasnya. Orang-orang telah membicarakan tentang mengubah kolom di sini selama _3 tahun_. Sementara itu SQL telah melakukan hal yang sama dengan baik selama 30 tahun.

Juga, RE: beralih antara PostgreSQL dan MySQL, apa yang terjadi jika Anda memutuskan untuk pindah dari javascript ke ruby? Berapa banyak waktu yang Anda perlukan untuk menyalin semua migrasi SQL Anda dari satu DSL konyol yang tidak berguna ke yang lain? Mungkin kita harus menulis DSL portabel, katamu? Itu SQL.

@tkellen Sementara saya lebih cenderung setuju dengan Anda akhir-akhir ini, saya pikir masih ada nilai dalam memiliki antarmuka untuk dengan mudah mengubah struktur database dari sisi javascript.

Sementara argumen tentang mudah mengubah server database sering muncul, saya pikir secara realistis itu bukan kasus penggunaan utama, karena alasan yang Anda sebutkan, dan karena ketika Anda membuat aplikasi Anda melakukannya dengan serangkaian dependensi dalam pikiran, termasuk database server. Dari sudut pandang saya, manfaat utamanya adalah hanya memiliki antarmuka standar yang memungkinkan fungsi ini di semua aplikasi Anda tanpa harus terus-menerus menulis hal yang sama berulang-ulang, atau terus-menerus menyertakan metode pembantu pribadi Anda sendiri.

Artinya, alih-alih semua orang menulis kode mereka sendiri untuk ini, dan berakhir dengan banyak cara berbeda untuk menyelesaikannya, kita akan memiliki semacam cara standar untuk melakukannya. Saya tahu bahwa SQL sudah menjadi sesuatu yang standar, tetapi terlalu umum. Menggunakan SQL saja Anda dapat melakukannya di mana saja dan kapan saja, tetapi fitur ini tentang menyesuaikannya dengan sesuatu yang lebih spesifik, membuatnya lebih dapat diprediksi.

Mengubah struktur database mungkin adalah sesuatu yang dimiliki oleh sejumlah besar program yang menggunakan database, jadi itu membuat kandidat yang baik untuk memiliki modul yang melakukan semua pekerjaan berat.

Apa saran Anda untuk masalah ini?

Saran saya adalah menggunakan sesuatu seperti careen , db-migrate , dll.

Pada dasarnya, temukan abstraksi seminimal mungkin dan gunakan itu. Itu berarti sesuatu untuk menjalankan file SQL sewenang-wenang, fasilitas untuk melacak yang telah dijalankan, dan beberapa fungsi untuk menggulungnya ke atas atau ke bawah.

Menurut pendapat saya, migrasi tidak pernah termasuk dalam Knex. Saya mencoba menggunakannya bertahun-tahun yang lalu, berasal dari latar belakang ruby ​​​​menggunakan Sekuel dan ActiveRecord. Seperti kebanyakan orang di utas ini, saya membayangkan bahwa suatu hari nanti kami akan memiliki tingkat dukungan yang sama di sini. Saya bahkan mendapatkan beberapa PR yang menambahkan fungsionalitas ke sistem migrasi.

Pada titik tertentu, saya mengenali dua hal:

1. Upaya monumental akan diperlukan untuk mencapai paritas fitur dengan alat yang lebih matang.
2. Alat dewasa masih sangat tidak lengkap dan memberikan nilai nol di atas SQL.

Misalnya, berikut adalah batasan pemeriksaan yang mencegah karyawan memesan ganda pada jadwal.

ALTER TABLE utilization ADD CONSTRAINT employee_over_utilized EXCLUDE USING gist (
  employee_id
  WITH =,COALESCE(sketch_calendar_id::text, 'null')
  WITH =,BOX(
    POINT(EXTRACT(EPOCH FROM first_day), EXTRACT(EPOCH FROM first_day)),
    POINT(EXTRACT(EPOCH FROM last_day), EXTRACT(EPOCH FROM last_day))
  )
  WITH &&
);

Anda tidak dapat membuat batasan seperti ini dengan lancar menggunakan DSL yang saya ketahui. Bahkan jika Anda bisa, saya tetap tidak akan mengeluarkan usaha untuk mempelajarinya. SQL melakukan semua yang Anda inginkan. Gunakan. Menempatkan veneer javascript jelek di atasnya tidak membantu siapa pun menyelesaikan apa pun.

Beralih antara MySQL dan PostgreSQL dengan mulus adalah mimpi yang tidak akan pernah terjadi pada siapa pun dalam skala yang berarti.

Sementara mengalihkan sistem produksi dari satu db ke yang lain itu sulit, itu bukan tidak mungkin. Meskipun demikian, saya pikir Anda benar-benar kehilangan seluruh kasus penggunaan ORM di sini. Bagaimana dengan perangkat lunak yang memungkinkan Anda memilih DB saat Anda menginstalnya? Itu yang sedang saya kerjakan

Knex bekerja dengan sangat baik di sebagian besar tempat karena menyediakan API yang hebat (atau veneer javascript jika itu yang Anda ingin menyebutnya) untuk kasus penggunaan yang paling umum, dan kemudian ia memiliki katup keluar knex.raw yang memungkinkan Anda dropdown ke keajaiban SQL ketika Anda harus melampaui dasar-dasar itu. Semua perpustakaan JavaScript yang baik bekerja dengan cara ini - mereka membungkus semuanya dengan ajaib tetapi membiarkan Anda melarikan diri saat Anda membutuhkannya.

Ketika datang ke sistem migrasi, masalah ini berbicara tentang beberapa kasus umum yang akan bagus untuk memiliki veneer karena kompleksitas perbedaan antara versi SQL - yaitu, tidak ada satu query SQL yang akan bekerja untuk beberapa DB. Itu tidak mengusulkan bahwa setiap kemungkinan migrasi harus memiliki abstraksi.

Terima kasih, saya sedang mencoba db-migrate sekarang. Sejauh ini bagus.

Sementara mengalihkan sistem produksi dari satu db ke yang lain itu sulit, itu bukan tidak mungkin. Meskipun demikian, saya pikir Anda benar-benar kehilangan seluruh kasus penggunaan ORM di sini. Bagaimana dengan perangkat lunak yang memungkinkan Anda memilih DB saat Anda menginstalnya? Itu yang sedang saya kerjakan

Jika saya memelihara Ghost, saya akan memiliki file migrasi terpisah untuk setiap RDBMS. Ya, Anda akan memiliki beberapa duplikasi kecil di basis kode Anda, tetapi seberapa banyak kejelasan yang akan diberikan untuk kontributor baru? Apakah rangkaian pengujian Anda yang ada dengan mudah menutupi kegagalan? Apakah Anda dapat dengan lebih mudah memanfaatkan kekuatan masing-masing basis data yang Anda dukung dengan menjatuhkan bangunan ini?

Lebih menarik lagi, ini bukan kasus penggunaan ORM.

Knex bekerja dengan sangat baik di sebagian besar tempat karena menyediakan API yang hebat (atau veneer javascript jika itu yang Anda ingin menyebutnya) untuk kasus penggunaan yang paling umum, dan kemudian ia memiliki katup keluar dari knex.raw yang memungkinkan Anda dropdown ke keajaiban SQL ketika Anda harus melampaui dasar-dasar itu. Semua perpustakaan JavaScript yang baik bekerja dengan cara ini - mereka membungkus semuanya dengan ajaib tetapi membiarkan Anda melarikan diri saat Anda membutuhkannya.

Setuju--Saya melihat nilai dalam pembuat kueri di atas munging string SQL, Knex sangat bagus untuk itu!

Ketika datang ke sistem migrasi, masalah ini berbicara tentang beberapa kasus umum yang akan bagus untuk memiliki veneer karena kompleksitas perbedaan antara versi SQL - yaitu, tidak ada satu query SQL yang akan bekerja untuk beberapa DB. Itu tidak mengusulkan bahwa setiap kemungkinan migrasi harus memiliki abstraksi.

Saya mengerti maksud Anda di sini, tetapi sudah tiga tahun dan kami masih berbicara tentang mengubah kolom. Juga, di mana Anda menggambar garis pada dasarnya? Sebagai contoh, saya menganggap batasan pemeriksaan yang kuat sebagai prinsip dasar desain database yang baik.

Jadi, saya baru saja membaca seluruh utas, dan tidak jelas bagi saya apa statusnya saat ini. Bisakah pengelola menjawab yang berikut ini?

1. Bagaimana status dokumentasi internal saat ini? Yaitu, informasi tentang bagaimana basis kode disusun, mengapa disusun seperti itu, dan seterusnya.
2. Bagaimana status permintaan fitur ini saat ini? Bagian mana yang sudah dilaksanakan, bagian mana yang belum? Di mana 'titik lampiran' potensial untuk menerapkan sisanya?
3. Apa, jika ada, pemblokir _pada saat ini_ untuk menerapkan ini dan mengirimkan PR? Bagian mana dari arsitektur internal yang perlu diubah dan bagaimana membuat hal ini menjadi mungkin?

Saya berpotensi tertarik untuk menerapkan ini dan mengirimkan PR, tetapi sebelum saya dapat berkomitmen untuk melakukan itu, saya harus memiliki gagasan yang lebih baik tentang seperti apa situasi saat ini, dan seberapa banyak pekerjaan yang dapat saya harapkan.

@joepie91

1. Tidak ada dokumentasi pengembang lain, kecuali kodenya. CONTRIBUTING.md menjelaskan beberapa hal tentang cara menjalankan tes, dll.
2. Sejauh yang saya tahu belum ada upaya untuk menerapkan ini. Jika seseorang mulai menerapkan ini, saya dapat membantu dengan mencoba menemukan beberapa permintaan tarik terkait di mana misalnya penggantian nama kolom diimplementasikan.
3. Saya tidak mengetahui adanya pemblokir, mengapa ini tidak dapat diterapkan. Saya tidak percaya bahwa seseorang harus mengubah arsitektur internal untuk ini. Saya akan merekomendasikan untuk memilih satu hal spesifik yang ingin Anda modifikasi dan implementasikan terlebih dahulu dan kemudian pilih hal berikutnya apa yang akan dimodifikasi dan diterapkan. Saya kira tantangan terbesar adalah menemukan kueri yang benar untuk setiap dialek untuk perubahan tertentu.

Orang yang tahu lebih baik merasa bebas untuk mengoreksi / menambahkan info di sini, saya hanya ingin menjawab sesuatu untuk memulai sehingga pertanyaan itu tidak akan hanya tinggal diam di sana ...

@elhigu Apa yang Anda katakan sebagian besar benar, tetapi ada beberapa penolakan dari beberapa kolaborator untuk menggabungkan ini. Tim sendiri tampaknya setuju jika ada yang benar-benar melakukan semua pekerjaan termasuk tes.

Tantangan terbesar adalah sehubungan dengan SQLite yang tidak mendukung modifikasi kolom secara native, sehingga memerlukan segala macam solusi.

@ricardograca Kami telah mendukung API yang tidak bekerja pada setiap dialek. Khususnya dengan sqlite ada beberapa fitur, yang hanya membuang pengecualian tidak didukung atau diabaikan begitu saja seperti .returning() .

Jadi saya tidak keberatan jika misalnya metode modifikasi kolom tertentu tidak berfungsi pada sqlite jika sebenarnya hampir tidak mungkin untuk diterapkan tanpa membuat beberapa kolom sementara + migrasi data untuk mendukungnya.

👍 besar di sini.

Diimplementasikan pada #1759

@elhigu Saya pikir ini adalah kesalahan?

1. ganti nama kolom
2. ubah tipe datanya
3. tambahkan atau jatuhkan batasan nol
4. ubah defaultnya

Hanya 1 dan 3 yang diterapkan.

Tunggu, abaikan saya - saya melihat PR yang menambahkan ini adalah #1914 - tautannya benar-benar membingungkan saya! Ini sangat mengasyikkan

@ErisDS ya, saya ingin menautkan PR asli dengan sebagian besar diskusi, seharusnya menautkan keduanya :)

Ok, jadi kita bisa mengubah tabel, kolom, dll.

Apakah ada cara sederhana untuk menyemai hanya ke kolom?

@PierBover apa yang Anda maksud dengan "penyemaian hanya untuk kolom"?

Jika misalnya kita menambahkan kolom baru, apakah ada cara sederhana untuk mengisinya dengan nilai selain menggunakan kueri mentah?

@PierBover Anda menggunakan defaultTo() saat membuat kolom atau pertama membuat data dan kemudian memperbaruinya dengan kueri knex normal. Tidak ada sihir tambahan di knex untuk ini (dan saya pikir seharusnya tidak ada juga).

return knex.schema.alterTable('MyTable', t => {
  // deafault value / expression to seed (one cannot create select queries here)
  t.integer('newColumn').defaultTo(1);
  t.integer('newColumn2').defaultTo(knex.raw('some expression e.g to create random data')); 
}).then(() => {
  // just create populate query after creating new column like normally done with SQL
  return knex('MyTable').update({ newColumn: 2, newColumn2: 3 });
});

@PierBover Ya: http://knexjs.org/#Seeds -CLI

Benar @ricardograca tapi itu untuk menyemai seluruh tabel, bukan?

Terima kasih atas sarannya @elhigu 👍

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