Knex: Knex.Schema: ¿Cómo crear una clave única compuesta?

Creo que deberías poder hacer esto con:

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

Avísame si no parece estar funcionando.

Funciona, gracias! Preparándose para cambiar de Sequelize.

intento ejecutar una migración

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

Pero no obtendré un índice único

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

¿Qué puede estar mal?

@ theo-ptz La API cambió hace un tiempo. Según los documentos , unique ahora es un método encadenable que usaría de la misma manera que usa primary y notNullable .

@bendrucker , gracias.

Pero algo no funciona.
Trato de ejecutar este código

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

Vi esto en depuración
--> ComQueryPacket { command: 3, sql: 'create table usuarios ( id int(11) unsigned not null auto_increment primary key, red varchar(3) not null, uid varchar(64), created_at datetime, updated_at datetime) default character set utf8' }

No obtuve un índice.

 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

¿Qué puede estar mal?

¿Existe alguna forma de crear un índice único compuesto en la migración?

Consulte las pruebas de integración para ver un ejemplo de una restricción única compuesta:

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

@bendrucker cuando se vincula a un archivo fuente, utilice una etiqueta / confirmación en lugar de maestro:
Su enlace que ya no funciona: https://github.com/tgriesser/knex/blob/master/test/integration/schema/index.js#L92
VS lo que quisiste decir: https://github.com/tgriesser/knex/blob/0.5.11/test/integration/schema/index.js#L92
Y usando la última versión (0.8.6): https://github.com/tgriesser/knex/blob/0.8.6/test/integration/schema/index.js#L157

Sugerencia: si presiona la tecla "y" mientras navega en github, cambia a la URL sha actual para el archivo actual que está viendo. Muy conveniente, me gustaría que github lo hiciera automáticamente cuando pegas una URL gh en un comentario

¿Esta función ha quedado obsoleta porque no está en la documentación?

@RichardSimko De acuerdo con el conjunto de pruebas, la sintaxis table.unique([...]) para claves compuestas todavía es compatible, por lo que parece un error con la documentación.

Sí, me di cuenta de que todavía funcionaba, solo me preocupaba que estuviera a punto de ser eliminado debido a que no estaba en los documentos.

Entonces, ¿cuál es la diferencia entre table.unique([...]) y table.primary([...]) ?

Según los documentos, parece que usar primary([...]) es la forma correcta de hacer claves primarias compuestas:

Cuando se llama en una sola columna, establecerá esa columna como la clave principal para una tabla. Para crear una clave primaria compuesta, pase una matriz de nombres de columna: table.primary(['column1', 'column2']) . El nombre de la restricción tiene como valor predeterminado tablename_pkey menos que se especifique constraintName .

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