Knex: Knex.Schema: Wie erstelle ich einen zusammengesetzten eindeutigen Schlüssel?

Ich glaube, Sie sollten dies tun können mit:

Knex.Schema.createTable('tableName', function(table) {
  table.unique(['LoginID', 'Email']);
  table.unique('LoginID');
  table.unique('Email');
});

Lassen Sie mich wissen, wenn es nicht funktioniert.

Funktioniert, danke! Vorbereiten des Wechsels von Sequelize.

Ich versuche eine Migration durchzuführen

knex.schema.createTable('users', function (table) {
        table.increments('id').primary();
        table.string('network', 3).notNullable();
        table.string('uid', 64).notNullable();
        table.unique(['network', 'uid']);
        table.timestamps();
}).then(function () {
        console.log('Users Table is Created!');
});

Aber ich werde keinen eindeutigen Index bekommen

CREATE TABLE `users` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `network` varchar(3) NOT NULL,
  `uid` varchar(64) NOT NULL,
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Was kann falsch sein?

@ theo-ptz Die API hat sich vor einiger Zeit geändert. Gemäß den Dokumenten ist unique jetzt eine verkettbare Methode, die Sie genauso verwenden würden, wie Sie primary und notNullable .

@ Bendrucker , danke.

Aber etwas funktioniert nicht.
Ich versuche diesen Code auszuführen

knex.schema.createTable('users', function (table) {
    table.increments('id').primary();
    table.string('network', 3).notNullable();
    table.string('uid', 64).unique();
    table.timestamps();
})

Ich habe das beim Debuggen gesehen
--> ComQueryPacket { command: 3, sql: 'create table Benutzer ( id int(11) unsigned not null auto_increment primary key, Netzwerk varchar(3) not null, uid varchar(64), created_at datetime, update_at datetime) default character set utf8' }

Ich habe keinen Index bekommen.

 CREATE TABLE `users` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `network` varchar(3) NOT NULL,
  `uid` varchar(64) DEFAULT NULL,
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Was kann falsch sein?

Gibt es überhaupt eine Möglichkeit, bei der Migration einen zusammengesetzten eindeutigen Index zu erstellen?

In den Integrationstests finden Sie ein Beispiel für eine zusammengesetzte eindeutige Einschränkung:

https://github.com/tgriesser/knex/blob/master/test/integration/schema/index.js#L92

@bendrucker Wenn Sie auf eine Quelldatei verlinken, verwenden Sie bitte ein Tag / Commit anstelle von master:
Ihr Link, der nicht mehr funktioniert: https://github.com/tgriesser/knex/blob/master/test/integration/schema/index.js#L92
VS was Sie meinten: https://github.com/tgriesser/knex/blob/0.5.11/test/integration/schema/index.js#L92
Und mit der neuesten Version (0.8.6): https://github.com/tgriesser/knex/blob/0.8.6/test/integration/schema/index.js#L157

Protip: Wenn Sie beim Surfen auf Github die Taste "y" drücken, wird zur aktuellen sha-URL für die aktuell angezeigte Datei gewechselt. Super praktisch, ich wünschte, Github würde das einfach automatisch tun, wenn Sie eine Gh-URL in einen Kommentar einfügen

Wurde diese Funktion nicht mehr unterstützt, da sie nicht in der Dokumentation enthalten ist?

@RichardSimko Laut Testsuite wird die Syntax table.unique([...]) für zusammengesetzte Schlüssel weiterhin unterstützt, sodass es wie ein Fehler in der Dokumentation aussieht.

Ja, mir wurde klar, dass es immer noch funktioniert. Ich war nur besorgt, dass es bald entfernt wird, weil es nicht in den Dokumenten enthalten ist.

Was ist der Unterschied zwischen table.unique([...]) und table.primary([...]) ?

Gemäß den Dokumenten scheint die Verwendung von primary([...]) der richtige Weg zu sein, um zusammengesetzte Primärschlüssel zu erstellen:

Beim Aufruf einer einzelnen Spalte wird diese Spalte als Primärschlüssel für eine Tabelle festgelegt. Übergeben Sie zum Erstellen eines zusammengesetzten Primärschlüssels ein Array mit Spaltennamen: table.primary(['column1', 'column2']) . Der Name der Einschränkung ist standardmäßig tablename_pkey sofern nicht constraintName angegeben ist.

http://knexjs.org/#Schema -primary