Knex: ¿Cómo cambiar la restricción anulable en la columna dentro de una migración?

Creado en 22 feb. 2016  ·  10Comentarios  ·  Fuente: knex/knex

Estoy tratando de cambiar una restricción en una columna, pero esto parece intentar volver a crear la columna y falla.

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

Comentario más útil

Para aquellos de ustedes que vienen aquí desde Google, la sintaxis es:

Conversión de una columna que no admite valores NULL para que admita valores NULL (invierta el up / down si desea que una columna que no admite valores NULL sea nulable).

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

Todos 10 comentarios

@Rush Realmente no creo que .nullable() y .notNullable() estén destinados a usarse para esto. Me parece que quieres ejecutar algo como

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

Y actualmente no puedo encontrar nada en la API aparte de .raw que pueda manejar esto.

@ rhys-vdw ¿Cuál es tu opinión sobre esto? ¿Podría .dropNotNull() / .setNotNull() o similar ser una valiosa adición al schemaBuilder? Sería muy similar a la implementación de .dropForeign() .

¿Podría .dropNotNull () /. SetNotNull () o similar ser una valiosa adición al schemaBuilder?

Sí, pero probablemente como .dropNullable(...columnNames) y .setNullable(...columnNames) .

@ rhys-vdw Pensándolo bien, creo que esto será demasiado inconveniente para cualquier dialecto que no sea postgres. Personalmente, no veo una buena solución para lo siguiente:

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?

Resultaría en argumentos inconsistentes basados ​​en el dialecto que está ejecutando. Postgres solo quiere nombre, mientras que otros quieren nombre + tipo de datos (+ valor predeterminado?).

¿Qué crees que vale la pena?

Solíamos admitir tanto SQLite como Postgres, pero SQLite es tan diferente que ninguna abstracción puede ocultarlo ... por lo que lanzar una excepción es probablemente lo correcto en tales casos. Las migraciones de ActiveRecord de Rails admiten cambios en las restricciones, por lo que tal vez ese sea el lugar para inspirarse.

Después de todo, esto fue posible de implementar. Hice un PR.

+1 - Acabo de encontrarme con este problema también, y es una especie de bloqueador. Siempre que necesite realizar una migración que asigne representaciones para columnas que no aceptan valores NULL, lo necesitará.

@morungos no es realmente un bloqueador, ya que siempre puedes ir a knex.raw para buscar cosas que para knex no tienen API especializadas (muchas cosas al escribir migraciones).

Si esta solicitud de extracción finaliza, este problema también se puede cerrar https://github.com/tgriesser/knex/pull/1759

Sí, he usado .raw varias veces, pero si se convierte en declaraciones completas, comienza a cuestionar todo el uso de las migraciones de rodilla. Al final, utilicé una solución alternativa: simplemente establezca un valor extraño no nulo, luego aplique reglas de mapeo para actualizar los valores y luego elimine el original. Pero puede resultar difícil hacerlo si está aplicando la integridad, especialmente con MySQL y es un hábito desagradable de requerir integridad incluso durante los pasos intermedios.

Para aquellos de ustedes que vienen aquí desde Google, la sintaxis es:

Conversión de una columna que no admite valores NULL para que admita valores NULL (invierta el up / down si desea que una columna que no admite valores NULL sea nulable).

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

Solo para su información, en caso de que esté tratando de cambiar nullable a nonNullable , primero debe completar esa columna con algo; de lo contrario, obtendrá un error.

Para aquellos de ustedes que vienen aquí desde Google, la sintaxis es:

Conversión de una columna que no admite valores NULL para que admita valores NULL (invierta el up / down si desea que una columna que no admite valores NULL sea nulable).

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();
    });
};
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

saurabhghewari picture saurabhghewari  ·  3Comentarios

tjwebb picture tjwebb  ·  3Comentarios

fsebbah picture fsebbah  ·  3Comentarios

ghost picture ghost  ·  3Comentarios

lanceschi picture lanceschi  ·  3Comentarios