Knex: Spalten ändern

Checkliste:

• [x] Spalten umbenennen
• [ ] NULL ändern
• [ ] Standard ändern
• [ ] Datentyp ändern

Die Unterstützung für das Umbenennen von Spalten ist sehr einfach, sie unterstützt beispielsweise nicht das Umbenennen von Feldern, die ein Fremdschlüssel sind, wie ich unter #157 berichtet habe.

Anerkannt – werfen Sie einen Blick auf die Checkliste in Tims Post zwei über Ihrem. Wenn dies für Sie eine Priorität ist und Sie es sofort benötigen, würden wir uns über eine PR sehr freuen.

Wir brauchen diese Funktionalität auch für @lemonde CMS.

Das Hinzufügen eines Indexes oder das Ändern einer Aufzählung sollte möglich sein, ohne Rohabfragen auszuführen.

@neoziro Im Moment sind Sie darauf beschränkt, eine bestimmte Spalte als Index festzulegen. Andere Schemaänderungen stehen auf der Todo-Liste, und wie immer sind PRs willkommen, wenn Sie etwas dringend brauchen.

Außerdem habe ich gerade einen Thread gestartet, um ausgewählte Anwendungsfälle für Knex/Bookshelf zu sammeln. Ich würde gerne hören, wie Sie Knex bei @lemonde verwenden. Sie können hier teilen: #170.

@bendrucker Ich verstehe Ihre Haltung zur Einreichung einer PR vollkommen. Ich hoffe, dass ich versuchen kann, einige von Ghosts Ressourcen umzuleiten, um dies zu erledigen, aber wir haben im Moment sehr begrenzte Ressourcen.

Da einige von uns auf diese Funktion hoffen, wäre es vielleicht gut, einige Gedanken von @bendrucker / @tgriesser darüber zu bekommen, wie die API aussehen sollte (ist mein Vorschlag oben richtig) und vielleicht irgendwelche Gedanken zu machen oder Ideen, wie dies erreicht werden kann / der bevorzugte Ansatz.

Im Moment sind viele der Ideen/Prinzipien darüber, wie Sachen im Knex/Bücherregal funktionieren und funktionieren sollten, immer noch (soweit ich das finden kann) im Kopf von @tgriesser ... Ich merke, dass er keinen großen hat viel Zeit, aber vielleicht eine Wiki-Seite voller Ideen, woher die Inspiration für verschiedene Teile kam, Ideen für die Zukunft, schlaues Zeug, das in der Bibliothek ist und warum, all die Insider-Informationen, damit wir alle nachholen können, was Sie waren denk nach und versuche so weiterzumachen, wie du es gutheißen würdest :sonnenbrille:

Oder vielleicht könntest du alles bloggen.. du weißt schon.. auf Ghost :wink:

Haha, auf jeden Fall... Entschuldigung @ErisDS und alle... Ich muss mir wirklich etwas Zeit nehmen, um mich hinzusetzen und ein paar Sachen zu schreiben, die mir noch im Kopf herumschwirren. Hoffentlich wird eine Menge Zeug, einschließlich all der oben genannten, geklärt, sobald ich mehr interne Konsistenz beim Erstellen von Abfragen in Knex habe. An diesem Punkt kann ich mich mehr auf die Organisation von Funktionen konzentrieren, die ich für Bookshelf geplant habe (Modelltypumwandlung, vorläufige Löschungen, ein zusammengesetztes Key-Plugin usw.).

Ich denke, es wäre auch wirklich toll, eine Open-Source-Beispiel-App zusammenzustellen (außer Ghost), die einige der verschiedenen Funktionen von Knex/Bookshelf zeigt, damit die Leute sie sich ansehen können. Ich hatte mit einem Hacker-News-Klon begonnen, hatte aber noch keine Zeit, ihn fertigzustellen ... @bendrucker , @johanneslumpe , @tkellen oder hat sonst jemand Interesse daran, bei so etwas zu helfen?

@tgriesser Ich empfehle dringend, sich einfach hinzusetzen und auszuspucken, was einem in den Sinn kommt, anstatt zu versuchen, es durch Code zu klären. Ab einem bestimmten Punkt lassen sich die Prinzipien viel einfacher mit Worten vermitteln.

Ich persönlich finde es entmutigend, zu knex & bookshelf beizutragen, weil ich das Gefühl habe, nicht genug Hintergrundinformationen oder Anleitungen zu haben, wie ich mich einarbeiten kann - obwohl ich mich stark auf diese Bibliotheken verlasse und sie einigermaßen gut kenne.

@ErisDS Ich unterstütze ein Wiki für "clever-ass stuff" :smile:

@tgriesser Ich würde auf jeden Fall mit der OS-Beispiel-App helfen

Große Änderungen sollten wahrscheinlich auf andere Refactors warten, aber ich denke, es lohnt sich, auch einen Non-Breaking-Refaktor der Schema-Builder-API in Betracht zu ziehen. Im Moment gibt es eine seltsame Mischung aus Versprechungen, verkettbaren Synchronisierungsfunktionen und Rückrufen. Vielleicht gibt table.column(name) ein ChainableColumn zurück und dann verketten alle Typfunktionen ( integer , text , etc.) davon.

Dann gäbe es die Methoden create , drop , rename , um die tatsächliche SQL-Spaltenoperation festzulegen ( ADD , ALTER , DROP ). create wäre der Standardwert.

Für mich passt das stilistisch besser zum Rest von Knex. Verketten Sie einfach alle Ihre Abfragekomponenten und lassen Sie die Magie geschehen, anstatt sich mit einer Tonne Camelcase-Syntax wie dropColumn und anderen herumzuschlagen.

@tgriesser Ich könnte _wahrscheinlich_ beim BocoupFest im Februar (4.-7.) einen Knex/Bookshelf-Hacker-News-Klon bekommen. Vielleicht könnten @tbranyen und ich einen zaubern. Ich werde es dich wissen lassen.

@tgriesser Natürlich! Ich helfe wo ich kann!

von meinem Iphone gesendet

Am 24. Januar 2014 um 17:25 Uhr schrieb Tyler Kellen [email protected] :

@tgriesser Ich könnte wahrscheinlich im Februar (4.-7.) beim BocoupFest einen Hacker-News-Klon von Knex/Bookshelf bekommen. Vielleicht könnten @tbranyen und ich einen zaubern. Ich werde es dich wissen lassen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

@tgriesser

Wie @ErisDS im ursprünglichen Beitrag erwähnt hat, wäre es schön, wenn ich mit der Migrationsfunktion von knex Spalten auf SQLite3 löschen oder umbenennen könnte.

lib/migration.js und lib/cli/migrate.js wissen nicht, auf welchen Client sie abzielen und welche Aktion zur Migrationszeit ausgeführt wird. Sie implementieren die Migration über die Abfrageerstellungsfunktionen von knex. Aber um das Löschen oder Umbenennen von Spalten auf SQLite3 zu implementieren, müssen wir nur dann, wenn der Client SQLite3 ist und die durchgeführte Aktion das Umbenennen oder Löschen ist, eine Tabelle zum Kopieren von Daten erstellen und Daten aus der ursprünglichen Tabelle in die zu kopierende Tabelle kopieren , löschen Sie die ursprüngliche Tabelle, erstellen Sie eine neue Tabelle, kopieren Sie Daten in die neue Tabelle und löschen Sie die Tabelle, um Daten zu kopieren.

Wenn diese Migrationsfunktion implementiert werden sollte, wo sollte Ihrer Meinung nach dieses Switching-Zeug platziert werden?

Hinweis: Derzeit benenne ich in meinem Projekt als Problemumgehung Spalten in Migrationsdateien wie folgt um (oder lösche sie):

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');
      });
  }
};

Ja, absetzen/ändern wäre schön. Im Grunde ist es nur mühsam zu implementieren, und weil die Dinge intern nicht ganz konsistent waren, habe ich zurückgehalten, weil die aktuelle Implementierung (ich bin mir ziemlich sicher, dass die Umbenennungsspalte derzeit funktioniert) eine Art riesiger Hack ist.

Dies ist die neue Version von renameColumn im kommenden 0.6.0-wip-Zweig:
https://github.com/tgriesser/knex/blob/6a2e3352a7cb9e6f989e7f572ef7ea1e363ef8e4/lib/clients/sqlite3/schema/tablecompiler.js#L81

Ich werde den größten Teil des Codes dort auch wiederverwenden, um eine Spalte zu löschen / Typen zu ändern, was etwas ist, von dem ich weiß, dass @ErisDS es auch wollte. Hoffentlich sollte diese Veröffentlichung in den kommenden Wochen fertig sein.

@tgriesser

Danke für deine Antwort.
Ihre neue Version von renameColumn ist sehr gut! :+1:

Ich freue mich auf Ihre Neuerscheinung.

Das sind hervorragende Neuigkeiten :+1:

Gibt es außer dem Beobachten von Problemen eine gute Möglichkeit, den Fortschritt zu verfolgen? Eine Roadmap, eine Mailingliste, ein IRC-Kanal oder ähnliches, wo all dieser Fortschritt organisiert wird? Ich bin sehr daran interessiert, auf dem Laufenden zu bleiben und zu helfen, wo es möglich ist.

Ja, wenn du bei #bookshelf vorbeischauen möchtest, bin ich normalerweise dort (muss ein bisschen Werbung für diesen Kanal machen). Werde in eine Roadmap schauen, kurz nachdem sich große Veränderungen mit den Interna stabilisiert haben.

Es sieht so aus, als wäre das Löschen von Fremdschlüsselspalten heutzutage auch möglich .

Ich bin mir nicht sicher, ob die Möglichkeit, die Länge von TEXT-Spalten zu ändern, als Teil davon auf dem Radar ist, also lass einfach eine Notiz fallen, dass dies etwas ist, was Ghost braucht.

Ich weiß, dass 0.7 in Arbeit ist, bringt uns das den „stabilisierten Interna“ näher, die eine Voraussetzung dafür waren, eine „clever-ass“-Dokumentation zu bekommen? :stuck_out_tongue_winking_eye:

+1 zum Ändern von null und nicht null in Spalten

@tgriesser , @bendrucker : Gab es ein Update zu dieser Funktionalität? Das Schreiben von Rohabfragen in jeder Migration, die ich habe, die eine Spalte ändert (praktisch alle), wird ein bisschen frustrierend.

Nein Entschuldigung

Wäre es möglich, die Methode renameColumn() (und eventuell andere Methoden zum Ändern von Spalten) so zu ändern, dass sie das geänderte Spaltenobjekt zurückgibt, sodass man jede der verkettbaren Spaltenmethoden damit verketten kann? Ich versuche nämlich, eine Referenz zu aktualisieren, nachdem ich eine Spalte umbenannt habe:

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

Dies erzeugt einen Fehler, der besagt, dass:

Object #<TableBuilder_PG> has no method 'references'

Wenn das eine Breaking Change wäre (sieht so aus, obwohl ich nicht sicher bin, ob jemand das aktuelle Rückgabeobjekt verwendet), dann bieten Sie zumindest eine Möglichkeit, eine bereits vorhandene Spalte auszuwählen.

Es tut mir leid, dass ich an einem alten Problem herumnörgele - aber ich möchte unbedingt die Länge von Textspalten ändern können. Ich würde gerne eingreifen und versuchen, dazu beizutragen, wenn es einen Konsens darüber gibt, was die API sein sollte?

Ist es noch möglich, Spaltentypen zu ändern, oder sollte ich .raw() verwenden?

@olalonde Nein, du solltest .raw() verwenden.

@ErisDS Der Plan ist, den Builder nicht auf normale Anweisungen zu beschränken, sondern auch eine API zum Ändern der Tabellen hinzuzufügen:

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

Ich arbeite auch an einer API zum Definieren, wie die Tabellenstruktur für eine Datenbank _sollte_, damit Sie diese Objekte schließlich verwenden können, um sie mit dem aktuellen Status der Datenbank zu vergleichen (ähnlich wie Ghost, aber etwas getesteter/ spezifiziert)

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

Ich arbeite daran, einige Dinge zu verschieben, um zu einer besseren API zu gelangen, als raw verwenden zu müssen

Nullable existiert, aber es ist nicht möglich, vorhandene Spalten wie auszuwählen

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

Aber Ihr Team hat gesagt, dass Sie daran arbeiten.

Wenn Sie den Code lesen, sieht es so aus, als hätte es diesbezüglich Fortschritte gegeben? https://github.com/tgriesser/knex/blob/master/src/schema/columnbuilder.js#L71

Chance auf ein Update? Wo stehen Sie mit diesen Veränderungen, was könnte getan werden, um zu helfen?

Irgendein Update dazu?

Sieht so aus, als könnten wir die Methode .alterTable oder so etwas verwenden?

Ich würde gerne eine API wie table.modifyColumn('myCol').notNullable().defaultTo('hello') sehen.

Stoßen!

Ich bin genauso gespannt wie jeder andere, dass sich in dieser Frage etwas bewegt. Wenn Sie damit einverstanden sind und etwas Bewegung zu diesem Thema anregen möchten, nehmen Sie sich am besten die Zeit, um zu erklären, was Ihr Anwendungsfall ist und warum Sie knex benötigen, um Unterstützung hinzuzufügen. Vielleicht sogar etwas Hilfe anbieten - Dokumentation und QA sind genauso nützlich wie Code.

Das Hinzufügen eines Kommentars ohne Inhalt wird hier wahrscheinlich keine Änderung des Status quo bewirken. Tatsächlich denke ich, dass es wahrscheinlicher ist, dass die Leute, von denen Sie hören möchten, dass Sie das Thema abbestellen.

Laut @ErisDS- Vorschlag ist meine Situation: Ich habe ein Schema mit dem Spaltentyp string , das ich in datetime ändern möchte. Ich bin offen für die Ausführung eines Prozesses, bei dem ich die vorhandene Spalte string lösche und eine neue mit datetime hinzufüge, und würde mich über eine Dokumentation dazu freuen.

@kuanb Dies ist ein Feature-Request-Thread - das bedeutet, dass es keine spezielle API dafür gibt. Im Moment müssen Sie andere schema.table -Methoden verwenden, um eine neue Spalte zu erstellen, die Daten zu kopieren und dann die ursprüngliche Spalte zu löschen. Wenn Sie dabei weitere Hilfe benötigen, würde ich vorschlagen, ein neues Problem zu eröffnen oder eine StackOverflow-Frage zu erstellen.

@rhys-vdw Entschuldigung für die Verwirrung, die ich verursacht habe. Meine Absicht war es, eine "Antwort" auf den @ErisDS- Kommentar zu geben, dass wir Anwendungsfälle einbeziehen sollten, um zu demonstrieren, dass so etwas notwendig ist. Ich verstehe, dass dies eine Feature-Anfrage ist.

Ich bin derzeit in der Lage, die Migration mit knex.raw( ... ) problemlos durchzuführen, wollte aber zeigen, dass ich in einer Situation war, in der eine solche Funktion aus der knex -Bibliothek nett gewesen wäre. Vielleicht habe ich die ErisDS-Anfrage falsch verstanden.

Ah richtig, ich habe nur geantwortet auf "und würde eine Dokumentation darüber schätzen, wie man das macht.". Kein Stress. :)

+1 für Änderung des Spaltendatumstyps

Ehrliche Frage. Dient diese Abstraktion tatsächlich einem sinnvollen Zweck? Schreiben Sie einfach SQL.

Knex sollte ein Abfragegenerator sein, kein Migrationssystem. Hier ist ein Beispiel für ein Migrationssystem, das zumindest ein wenig Sinn macht:

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

Warum muss ich SQL berühren? Stellen Sie sich einen Fall vor, in dem ich eines Tages von PostgreSQL zu MySQL wechseln möchte. Wie lange wird es dauern, bis ich alle Fallstricke auf beiden Seiten gelernt und alle rohen SQL-Migrationen neu geschrieben habe? Plus, wenn ActiveRecord die Migration richtig machen kann, warum kann Knex das nicht?

Der nahtlose Wechsel zwischen MySQL und PostgreSQL ist ein Wunschtraum, der für niemanden jemals in einem bedeutenden Umfang eintreten wird. Alle Datenbanksysteme haben Stärken und Schwächen. Es macht absolut keinen Sinn, sich auf eine Teilmenge zu beschränken, die für beide funktioniert, damit Sie willkürlich zwischen dem einen oder dem anderen wechseln können.

ActiveRecord macht Migrationen nicht "richtig". Es gibt eine riesige Menge an Funktionalität, für die es kein DSL gibt. Sie haben jedoch recht, dass mehr menschlicher Aufwand in das Migrationssystem von ActiveRecord gesteckt wurde. Der Grund dafür sind einfache Zahlen.

Knie:

Aktiver Rekord:

Meine Frage bleibt. Wo ist der Wert in diesen DSLs? Alles, was Sie migrieren möchten, kann in SQL ausgedrückt werden. Sie müssen keinen halbgebackenen Zucker darauf bauen. Die Leute haben hier seit _3 Jahren_ über das Ändern von Säulen gesprochen. In der Zwischenzeit hat SQL 30 Jahre lang das Gleiche getan.

Auch RE: Wechsel zwischen PostgreSQL und MySQL, was passiert, wenn Sie sich entscheiden, von Javascript zu Ruby zu wechseln? Wie viel Zeit benötigen Sie, um all Ihre SQL-Migrationen von einer dummen, sinnlosen DSL zu einer anderen zu transkribieren? Vielleicht sollten wir ein tragbares DSL schreiben, sagen Sie? Das ist SQL.

@tkellen Obwohl ich Ihnen heutzutage eher zustimme, denke ich, dass es immer noch sinnvoll ist, eine Schnittstelle zum einfachen Ändern der Struktur einer Datenbank von der Javascript-Seite aus zu haben.

Während das Argument über den einfachen Wechsel von Datenbankservern oft auftaucht, denke ich, dass dies aus den von Ihnen genannten Gründen realistischerweise nicht der Hauptanwendungsfall ist, und weil Sie beim Erstellen einer Anwendung eine Reihe von Abhängigkeiten im Auge behalten, einschließlich der Datenbank Server. Aus meiner Sicht besteht der Hauptvorteil darin, einfach eine Standardschnittstelle zu haben, die diese Funktionalität in all Ihren Apps ermöglicht, ohne dass Sie ständig dasselbe schreiben müssen oder ständig Ihre eigenen privaten Hilfsmethoden einbinden müssen.

Das heißt, anstatt dass jeder seinen eigenen Code dafür schreibt und am Ende viele verschiedene Möglichkeiten hat, dies zu erreichen, hätten wir eine Art Standardmethode, dies zu tun. Ich weiß, dass SQL bereits etwas Standard ist, aber es ist zu allgemein. Mit SQL allein können Sie es überall und jederzeit tun, aber bei dieser Funktion geht es darum, es auf etwas Spezifischeres zuzuschneiden und es vorhersehbarer zu machen.

Das Ändern der Struktur einer Datenbank ist wahrscheinlich etwas, das von einer großen Anzahl von Programmen geteilt wird, die eine Datenbank verwenden, daher ist es ein guter Kandidat für ein Modul, das die ganze schwere Arbeit erledigt.

Was ist Ihr Vorschlag zu diesem Problem?

Mein Vorschlag ist, so etwas wie careen , db- migrate usw. zu verwenden.

Finden Sie im Grunde die minimalste mögliche Abstraktion und verwenden Sie sie. Das bedeutet etwas, um beliebige SQL-Dateien auszuführen, eine Möglichkeit, zu verfolgen, welche ausgeführt wurden, und einige Funktionen, um sie nach oben oder unten zu rollen.

Migrationen gehörten meiner Meinung nach nie in Knex. Ich habe vor Jahren versucht, sie zu verwenden, da ich mit Sequel und ActiveRecord aus einem rubinroten Hintergrund kam. Wie die meisten Leute in diesem Thread habe ich mir vorgestellt, dass wir eines Tages hier das gleiche Maß an Unterstützung haben würden. Ich habe sogar einige PRs gelandet , die dem Migrationssystem Funktionalität hinzufügen.

Irgendwann sind mir zwei Dinge aufgefallen:

1. Es wäre ein enormer Aufwand erforderlich, um die Funktionsgleichheit mit ausgereifteren Tools zu erreichen.
2. Ausgereifte Tools sind immer noch sehr unvollständig und bieten keinen Mehrwert gegenüber SQL.

Hier ist zum Beispiel eine Check-Einschränkung, die verhindert, dass ein Mitarbeiter in einem Zeitplan doppelt gebucht wird.

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 &&
);

Sie können solche Beschränkungen nicht fließend mit irgendeiner mir bekannten DSL erstellen. Selbst wenn du könntest, würde ich mir trotzdem nicht die Mühe machen, es zu lernen. SQL tut alles, was Sie wollen. Benutze es. Ein beschissenes Javascript-Furnier darüber zu legen, hilft niemandem, etwas zu erledigen.

Der nahtlose Wechsel zwischen MySQL und PostgreSQL ist ein Wunschtraum, der für niemanden jemals in einem bedeutenden Umfang eintreten wird.

Das Umschalten eines Produktionssystems von einer DB auf eine andere ist zwar schwierig, aber nicht unmöglich. Trotzdem denke ich, dass Sie hier einen ganzen ORM-Anwendungsfall völlig vermissen. Was ist mit Software, mit der Sie Ihre DB auswählen können, wenn Sie sie installieren? Daran arbeite ich 😉

Knex funktioniert an den meisten Stellen wirklich gut, da es eine großartige API (oder Javascript-Furnier, wenn Sie es so nennen möchten) für die häufigsten Anwendungsfälle bietet, und dann hat es ein Auslassventil von knex.raw , mit dem Sie es können Drop-down zur Magie von SQL, wenn Sie über diese Grundlagen hinausgehen müssen. Alle guten JavaScript-Bibliotheken funktionieren auf diese Weise - sie verpacken die Dinge in Magie, lassen Sie aber entkommen, wenn Sie es brauchen.

Wenn es um das Migrationssystem geht, geht es in dieser Ausgabe um eine Handvoll häufiger Fälle, für die es aufgrund der Komplexität der Unterschiede zwischen SQL-Versionen großartig wäre, eine Fassade zu haben - das heißt, es gibt keine einzige SQL-Abfrage, die dies tun würde Arbeit für mehrere DBs. Es schlägt nicht vor, dass jede mögliche Migration jemals eine Abstraktion haben sollte.

Danke, ich probiere jetzt db-migrate aus. So weit, ist es gut.

Das Umschalten eines Produktionssystems von einer DB auf eine andere ist zwar schwierig, aber nicht unmöglich. Trotzdem denke ich, dass Sie hier einen ganzen ORM-Anwendungsfall völlig vermissen. Was ist mit Software, mit der Sie Ihre DB auswählen können, wenn Sie sie installieren? Daran arbeite ich 😉

Wenn ich Ghost betreuen würde, hätte ich separate Migrationsdateien für jedes RDBMS. Ja, Sie hätten einige geringfügige Duplizierungen in Ihrer Codebasis, aber wie viel Klarheit würde dies für neue Mitwirkende bieten? Würde Ihre vorhandene Testsuite Fehler problemlos abdecken? Wären Sie in der Lage, die Stärken der jeweiligen von Ihnen unterstützten Datenbanken leichter zu nutzen, indem Sie dieses Gebäude fallen lassen?

Genauer gesagt ist dies kein ORM-Anwendungsfall.

Knex funktioniert an den meisten Stellen wirklich gut, da es eine großartige API (oder Javascript-Veneer, wenn Sie es so nennen möchten) für die häufigsten Anwendungsfälle bietet, und dann hat es ein Escape-Ventil von knex.raw, mit dem Sie auf die herunterklappen können Magie von SQL, wenn Sie über diese Grundlagen hinausgehen müssen. Alle guten JavaScript-Bibliotheken funktionieren auf diese Weise - sie verpacken die Dinge in Magie, lassen Sie aber entkommen, wenn Sie es brauchen.

Einverstanden – ich sehe den Wert in einem Query Builder gegenüber dem Munging von SQL-Strings, Knex ist großartig dafür!

Wenn es um das Migrationssystem geht, geht es in dieser Ausgabe um eine Handvoll häufiger Fälle, für die es aufgrund der Komplexität der Unterschiede zwischen SQL-Versionen großartig wäre, eine Fassade zu haben - das heißt, es gibt keine einzige SQL-Abfrage, die dies tun würde Arbeit für mehrere DBs. Es schlägt nicht vor, dass jede mögliche Migration jemals eine Abstraktion haben sollte.

Ich verstehe, was Sie hier sagen, aber es ist drei Jahre her, und wir reden immer noch darüber, eine Kolumne zu ändern. Außerdem, wo ziehst du die Grenze bei Basic? Robuste Check Constraints halte ich zum Beispiel für einen Grundgedanken guten Datenbankdesigns.

Also, ich habe mir gerade den ganzen Thread durchgelesen, und es ist mir nicht klar, wie der aktuelle Stand ist. Könnte ein Betreuer folgendes beantworten?

1. Wie ist der aktuelle Stand der internen Dokumentation? Das heißt, Informationen darüber, wie die Codebasis strukturiert ist, warum sie so strukturiert ist und so weiter.
2. Wie ist der aktuelle Stand dieser Funktionsanfrage? Welche Teile wurden implementiert, welche nicht? Wo sind mögliche „Anknüpfungspunkte“ für die Umsetzung des Rests?
3. Was, wenn überhaupt, sind die Blocker _in diesem Moment_ dafür, dies zu implementieren und eine PR einzusenden? Welche Teile der internen Architektur müssen geändert werden und wie, um dies zu ermöglichen?

Ich bin möglicherweise daran interessiert, dies umzusetzen und eine PR einzureichen, aber bevor ich mich dazu verpflichten kann, muss ich eine bessere Vorstellung davon haben, wie die aktuelle Situation ist und wie viel Arbeit ich erwarten kann.

@joepie91

1. Außer dem Code gibt es keine weitere Entwicklerdokumentation. CONTRIBUTING.md beschreibt einige Dinge, wie man Tests usw. durchführt.
2. Soweit ich weiß, gab es keine Bemühungen, dies umzusetzen. Wenn man anfängt, dies zu implementieren, kann ich helfen, indem ich versuche, einige verwandte Pull-Requests zu finden, in denen zB Spaltenumbenennung implementiert ist.
3. Mir sind keine Blocker bekannt, warum dies nicht implementiert werden konnte. Ich glaube nicht, dass man dafür die interne Architektur ändern muss. Ich würde empfehlen, zuerst eine bestimmte Sache auszuwählen, die Sie ändern und implementieren möchten, und dann als Nächstes auszuwählen, was Sie ändern und implementieren möchten. Ich nehme an, dass die größte Herausforderung darin besteht, für jeden Dialekt eine korrekte Abfrage für bestimmte Änderungen zu finden.

Leute, die es besser wissen, können hier gerne korrigieren / ergänzen, ich wollte nur etwas beantworten, damit die Frage nicht nur in der Stille herumhängt ...

@elhigu Was Sie sagen, ist größtenteils richtig, aber einige Mitarbeiter wehren sich dagegen, dies zusammenzuführen. Tim selbst scheint damit einverstanden zu sein, wenn tatsächlich jemand die ganze Arbeit einschließlich der Tests macht.

Die größte Herausforderung wird in Bezug auf SQLite liegen, das das Ändern von Spalten nicht nativ unterstützt, sodass alle möglichen Problemumgehungen erforderlich sind.

@ricardograca Wir haben APIs unterstützt, die nicht in jedem Dialekt funktionieren. Speziell bei sqlite gibt es einige Funktionen, die nur eine Ausnahme auslösen, weil sie nicht unterstützt oder einfach ignoriert werden, wie .returning() .

Es macht mir also nichts aus, wenn zB bestimmte Methoden zum Ändern von Spalten auf SQLite nicht funktionieren, wenn es eigentlich so gut wie unmöglich ist, es zu implementieren, ohne einige temporäre Spalten + Datenmigrationen zu erstellen, um dies zu unterstützen.

Ein riesiges 👍 hier.

Implementiert in #1759

@elhigu Ich denke, das ist ein Fehler?

1. eine Spalte umbenennen
2. den Datentyp ändern
3. Fügen Sie die Null-Einschränkung hinzu oder löschen Sie sie
4. ändern Sie die Standardeinstellung

Nur 1 und 3 sind implementiert.

Warte, ignoriere mich – ich sehe die PR, die dies hinzufügt, ist #1914 – der Link hat mich total verwirrt! Das ist superspannend

@ErisDS ja, ich wollte die ursprüngliche PR mit den meisten Diskussionen verlinken, hätte beide verlinken sollen :)

Ok, wir können also eine Tabelle, eine Spalte usw. ändern.

Gibt es eine einfache Möglichkeit, nur eine Spalte zu säen?

@PierBover was meinst du mit "seeding only to a column"?

Wenn wir beispielsweise eine neue Spalte hinzufügen, gibt es eine einfache Möglichkeit, sie mit anderen Werten zu füllen, als einfache Abfragen zu verwenden?

@PierBover Sie verwenden entweder defaultTo() beim Erstellen der Spalte oder erstellen zuerst Daten und aktualisieren sie dann mit normalen Knex-Abfragen. Dafür gibt es in Knex keine zusätzliche Magie (und ich denke auch nicht, dass es eine geben sollte).

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 Ja: http://knexjs.org/#Seeds -CLI

Richtig @ricardograca , aber das ist dafür da, den ganzen Tisch zu säen, oder?

Danke für den Vorschlag @elhigu 👍

Ich starte hier ein neues Projekt, um Tabellen mit knex.js zu säen. Jede Hilfe wird nett sein!