EF Code Первое изменение типа данных bool? для bool и int? к внутреннему
У нас есть приложение, в котором мы используем автоматическую миграцию данных, и потеря данных не допускается. Согласно политике компании, мне не разрешено изменять эти настройки.
У нас также есть несколько столбцов с нулевым значением в нескольких таблицах bool? тип и интервал? тип.
Я только что обнаружил сегодня, что есть фрагмент кода, который просматривает существующие записи базы данных и устанавливает значения столбцов, допускающих значение NULL, в их значения по умолчанию (false и 0 соответственно). Текущее поведение замедляет работу приложения. Я хочу заставить базу данных/EF устанавливать значения по умолчанию и не допускать пустых значений.
До сих пор я безуспешно пробовал следующее:
- Прямое изменение типа с bool? для bool и int? в внутр. Выдает исключение потери данных.
- Добавление атрибутов [Required] и [DefaultValue(false)] поверх свойства, допускающего значение NULL. То же самое, исключение потери данных.
- Изменение .IsOptional() на .IsRequired() в классе сопоставления также вызвало такое же исключение.
По сути, я хочу воспроизвести в Code First EF следующий оператор MySQL:
ALTER TABLE orders
CHANGE COLUMN ScaleToFit ScaleToFit TINYINT(1) NOT NULL DEFAULT 0;
Есть ли изящные решения проблемы с политикой компании? Спасибо!
@ Matt.G только что попробовал. Установка DefaultValue сама по себе ничего не делает с уже существующими нулевыми значениями. Думаю, это повлияет только на будущие записи.
не уверен, что вы можете сделать что-нибудь для существующих данных в базе данных. Что происходит, когда вы пытаетесь получить эти данные в коде с атрибутом DefaultValue? возвращает false или null?
@Matt.G возвращает ноль
Ответы 1
Это может быть мой первый ответ, не связанный с программированием.
Я искренне надеюсь, что не существует элегантного решения — и вообще никакого решения — для достижения этого с помощью миграции. Это означало бы утечку в обнаружении потери данных, что было бы плохой новостью. Это считается потерей данных, потому что значение null может также нести информацию, т. е. преднамеренное «не знаю». В случае логического значения: три состояния превращаются в два состояния. Это неверно в вашем случае, отсюда и этот процесс исправления, но это не меняет правила.
By company's policy, I am not allowed to change those settings.
Политики обслуживать цель, но почти всегда цель превратиться в. Вероятно, потому, что политики легче определить, внедрить и проверить, чем их основное назначение. Но как в Закон Гудхарта...
When a measure becomes a target, it ceases to be a good measure
... каждая политика может однажды разрушить свою цель и перестать быть хорошей политикой. Способность признавать это и изменять политику, когда это необходимо, является похвальной чертой организаций.
Я пытаюсь сказать: предложите временную однократную приостановку этой политики, чтобы разрешить миграцию, при которой Только применяет эти необнуляемые поля со значениями по умолчанию. Если нулевые значения действительно бессмысленны и на самом деле должны были быть не нулевыми с самого начала, это самый простой способ добраться туда, куда вы хотите.
Я также предложил правильно обрабатывать нули в коде, вместо того, чтобы ожидать ненулевые значения. Однако это потребует больше изменений, чем пользовательская миграция.
вы пробовали только атрибут
DefaultValue(без атрибутаRequired)?