Knex: Wie ändere ich die Nullable-Einschränkung in einer Spalte innerhalb einer Migration?

Erstellt am 22. Feb. 2016  ·  10Kommentare  ·  Quelle: knex/knex

Ich versuche, eine Einschränkung für eine Spalte zu ändern, aber dies scheint nur zu versuchen, die Spalte neu zu erstellen, und schlägt fehl.

exports.up = function(knex, Promise) {  
  return knex.schema.table("images", function(table) {
    table.string("checksum").notNullable();
  });
};

exports.down = function(knex, Promise) {
  return knex.schema.table("images", function(table) {
    table.string("checksum").nullable();
  });
};
PR please feature request schema

Hilfreichster Kommentar

Für diejenigen von Ihnen, die von Google hierher kommen, lautet die Syntax:

Konvertieren einer vorhandenen nonNullable-Spalte in nullable (kehren Sie das Auf/Ab um, wenn Sie möchten, dass eine nonNullable nullable ist).

exports.up = knex => {
  return knex.schema
    .alterTable('images', (table) => {
      table.string('checksum').nullable().alter();
    });
};

exports.down = knex => {
  return knex.schema
    .alterTable('images', table => {
      table.string('checksum').notNullable().alter();
    });
};

Alle 10 Kommentare

@Rush Ich glaube wirklich nicht, dass .nullable() und .notNullable() dafür gedacht sind. Mir scheint, du möchtest so etwas wie laufen

ALTER TABLE tableName ALTER COLUMN columnName DROP NOT NULL
ALTER TABLE tableName ALTER COLUMN columnName SET NOT NULL

Und derzeit kann ich außer .raw nichts in der API finden, das damit umgehen könnte.

@rhys-vdw Was halten Sie davon? Könnte .dropNotNull() / .setNotNull() oder ähnliches eine würdige Ergänzung zum schemaBuilder sein? Es wäre der Implementierung von .dropForeign() sehr ähnlich.

Könnte .dropNotNull()/.setNotNull() oder ähnliches eine würdige Ergänzung zum schemaBuilder sein?

Ja, aber wahrscheinlich als .dropNullable(...columnNames) und .setNullable(...columnNames) .

@rhys-vdw Beim zweiten Nachdenken habe ich das Gefühl, dass dies für jeden anderen Dialekt als Postgres zu umständlich sein wird. Für folgendes sehe ich persönlich keine gute Lösung:

Postgres dropNullable: ALTER TABLE table ALTER COLUMN columnName DROP NOT NULL
Postgres setNullable: ALTER TABLE table ALTER COLUMN columnName SET NOT NULL

MSSQL dropNullable: ALTER TABLE table ALTER COLUMN columnName columnType NULL
MSSQL setNullable: ALTER TABLE table ALTER COLUMN columnName columnType NOT NULL

MySQL/Maria/Oracle dropNullable: ALTER TABLE table MODIFY columnName columnType NULL;
MySQL/Maria/Oracle setNullable: ALTER TABLE table MODIFY columnName columnType NOT NULL;

Sqlite: No support?

Dies würde zu inkonsistenten Argumenten basierend auf dem Dialekt führen, den Sie ausführen. Postgres wollen nur den Namen, während andere Name + Datentyp (+ Standardwert?) wollen.

Was meint ihr, ist es das wert?

Früher haben wir sowohl SQLite als auch Postgres unterstützt, aber SQLite ist so anders, dass keine Abstraktion es verbergen kann ... also ist es in solchen Fällen wahrscheinlich das Richtige, eine Ausnahme auszulösen. Die ActiveRecord-Migrationen von Rails unterstützen sich ändernde Einschränkungen. Vielleicht ist das der Ort, an dem Sie sich inspirieren lassen können?

Dies war doch umsetzbar. Ich habe eine PR gemacht.

+1 – Ich bin gerade auch auf dieses Problem gestoßen und es ist so etwas wie ein Blocker. Jedes Mal, wenn Sie eine Migration durchführen müssen, die Darstellungen für Spalten ohne NULL-Werte zuordnet, benötigen Sie dies.

@morungos nicht wirklich ein Blocker, da Sie immer zu knex.raw für Sachen wechseln können, die für Knex keine speziellen APIs haben (viele Sachen beim Schreiben von Migrationen).

Wenn dieser Pull-Request abgeschlossen ist, kann dieses Problem auch geschlossen werden https://github.com/tgriesser/knex/pull/1759

Ja, ich habe .raw ein paar Mal verwendet, aber wenn daraus ganze Aussagen werden, fängt es an, die gesamte Verwendung von Kniemigrationen in Frage zu stellen. Am Ende habe ich eine Problemumgehung verwendet: Standardmäßig einen seltsamen Wert ungleich Null verwenden, dann Zuordnungsregeln anwenden, um die Werte zu aktualisieren, und dann das Original löschen. Dies kann jedoch schwierig werden, wenn Sie Integrität erzwingen möchten, insbesondere bei MySQL, und es ist eine unangenehme Angewohnheit, Integrität auch bei Zwischenschritten zu fordern.

Für diejenigen von Ihnen, die von Google hierher kommen, lautet die Syntax:

Konvertieren einer vorhandenen nonNullable-Spalte in nullable (kehren Sie das Auf/Ab um, wenn Sie möchten, dass eine nonNullable nullable ist).

exports.up = knex => {
  return knex.schema
    .alterTable('images', (table) => {
      table.string('checksum').nullable().alter();
    });
};

exports.down = knex => {
  return knex.schema
    .alterTable('images', table => {
      table.string('checksum').notNullable().alter();
    });
};

Nur zu Ihrer Information, falls Sie versuchen, nullable in nonNullable zu ändern, müssen Sie diese Spalte zuerst mit etwas füllen, sonst erhalten Sie eine Fehlermeldung.

Für diejenigen von Ihnen, die von Google hierher kommen, lautet die Syntax:

Konvertieren einer vorhandenen nonNullable-Spalte in nullable (kehren Sie das Auf/Ab um, wenn Sie möchten, dass eine nonNullable nullable ist).

exports.up = knex => {
  return knex.schema
    .alterTable('images', (table) => {
      table.string('checksum').nullable().alter();
    });
};

exports.down = knex => {
  return knex.schema
    .alterTable('images', table => {
      table.string('checksum').notNullable().alter();
    });
};
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

aj0strow picture aj0strow  ·  3Kommentare

ghost picture ghost  ·  3Kommentare

mattgrande picture mattgrande  ·  3Kommentare

arconus picture arconus  ·  3Kommentare

tjwebb picture tjwebb  ·  3Kommentare