Knex: Как изменить ограничение, допускающее значение NULL, в столбце внутри миграции?

Созданный на 22 февр. 2016 · 10Комментарии · Источник: knex/knex

Я пытаюсь изменить ограничение в столбце, но это просто попытка воссоздать столбец и не удается.

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

Источник

Rush

👍12

Самый полезный комментарий

Для тех из вас, кто пришел сюда из Google, синтаксис следующий:

Преобразование существующего столбца nonNullable в допускающий значение NULL (поменяйте местами вверх / вниз, если вы хотите, чтобы столбец nonNullable допускал значение NULL).

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

et 20 февр. 2018

👍135 ❤32 🎉27

Все 10 Комментарий

@Rush Я действительно не думаю, что .nullable() и .notNullable() предназначены для этого. Мне кажется, вы хотите запустить что-то вроде

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

И в настоящее время я не могу найти в API ничего, кроме .raw что могло бы с этим справиться.

@ rhys-vdw Что вы думаете об этом? Может ли .dropNotNull() / .setNotNull() или подобное быть достойным дополнением к schemaBuilder? Это было бы очень похоже на реализацию .dropForeign() .

wubzz 22 февр. 2016

Может ли .dropNotNull () /. SetNotNull () или подобное быть достойным дополнением к schemaBuilder?

Да, но, вероятно, как .dropNullable(...columnNames) и .setNullable(...columnNames) .

rhys-vdw 25 февр. 2016

@ rhys-vdw Если подумать, мне кажется, что это будет слишком неудобно для любого диалекта, кроме postgres. Лично я не вижу хорошего решения следующего:

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?

Это приведет к противоречивым аргументам, основанным на вашем диалекте. Postgres хочет только имя, в то время как другим нужно имя + тип данных (+ значение по умолчанию?).

Как думаете, стоит?

wubzz 26 февр. 2016

Раньше мы поддерживали как SQLite, так и Postgres, но SQLite настолько отличается, что никакая абстракция не может скрыть его ... так что в таких случаях, вероятно, правильнее всего выбросить исключение. Миграции Rails ActiveRecord действительно поддерживают изменение ограничений, так что, может быть, это место для вдохновения?

Rush 26 февр. 2016

В конце концов, это удалось реализовать. Я устроил пиар.

wubzz 2 апр. 2016

+1 - Я тоже только что столкнулся с этой проблемой, и это что-то вроде блокиратора. Это понадобится вам каждый раз, когда вам нужно выполнить миграцию, отображающую представления для столбцов, не допускающих значения NULL.

morungos 4 янв. 2017

@morungos на самом деле не является блокировщиком, так как вы всегда можете перейти на knex.raw для того, что для knex не имеет специализированных API (много всего при написании миграций).

Если этот запрос на перенос завершен, эту проблему также можно закрыть https://github.com/tgriesser/knex/pull/1759

elhigu 4 янв. 2017

👍3

Да, я использовал .raw несколько раз, но если он превращается в целые утверждения, это начинает подвергать сомнению использование миграции колена в целом. В конце концов, я использовал обходной путь: просто по умолчанию использовал какое-то ненулевое странное значение, затем применил правила сопоставления для обновления значений, а затем отбросил оригинал. Но это может быть сложно сделать, если вы обеспечиваете целостность, особенно с MySQL, и это неприятная привычка требовать целостности даже на промежуточных этапах.

morungos 4 янв. 2017

Для тех из вас, кто пришел сюда из Google, синтаксис следующий:

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

et 20 февр. 2018

👍135 ❤32 🎉27

К вашему сведению, если вы пытаетесь изменить nullable на nonNullable вам сначала нужно чем-то заполнить этот столбец, иначе вы получите сообщение об ошибке.

Для тех из вас, кто пришел сюда из Google, синтаксис следующий:
Преобразование существующего столбца nonNullable в допускающий значение NULL (поменяйте местами вверх / вниз, если вы хотите, чтобы столбец nonNullable допускал значение NULL).
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();
    });
};