Использование значений DB-Default для несопоставленных битовых столбцов в структуре сущностей 4 (сначала база данных)

Я пытаюсь сопоставить два конкретных типа сущностей и абстрактный базовый тип с одной и той же таблицей базы данных.

Таблица содержит битовый столбец, который не принимает значение NULL. Столбец имеет значение по умолчанию: ((0)).

Только один из двух конкретных типов объектов (т. е. конкретный тип 1) должен использовать значение столбца (для другого (т. е. конкретного типа 2) оно всегда ложно).

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

Когда я вызываю SaveChanges, я получаю UpdateException со следующим сообщением о самом внутреннем исключении:
"Столбец не может содержать нулевые значения. [Имя столбца = MY_BIT_COLUMN, имя таблицы = MY_TABLE]"

Я уже отредактировал раздел SSDL в EDMX и изменил:

<Property Name="MY_BIT_COLUMN" Type="bit" Nullable="false" />

to:

<Property Name="MY_BIT_COLUMN" Type="bit" Nullable="false" DefaultValue="false" />

(Без этого изменения сопоставление не удалось - не запустится)

Есть ли способ обойти это, не добавляя свойство, сопоставленное с этим столбцом, ко второму конкретному типу сущности или перемещая его в базовый тип?

Добавление защищенного свойства к конкретному типу 2 действительно работает, но я бы предпочел более элегантный обходной путь.


entity-framework mapping default-value entity-framework-4 updateexception
person Danny Varod    schedule 03.05.2011    source источник
comment
Итак, как только вы добавили DefaultValue в SSDL, он все равно выдает исключение?   -  person Ladislav Mrnka    schedule 04.05.2011
comment
Да, он компилируется, но во время выполнения происходит сбой.   -  person Danny Varod    schedule 04.05.2011

Ответы (1)


arrow_upward
1
arrow_downward

Если ваш обходной путь не работает (я немного удивлен, но мне уже поздно тестировать его сейчас), тогда единственный другой обходной путь — изменить ваше наследование с TPH на TPT или TPC. Проблема, очевидно, заключается в том, что TPH требует, чтобы все столбцы в производных типах допускали значение NULL.

Другой обходной путь заключается в том, чтобы сделать ваш столбец членом родительского объекта, а в производном объекте использовать пользовательский конструктор, который всегда будет устанавливать для него значение false.

Последний обходной путь — сделать ваш столбец обнуляемым и применить проверку в вашей бизнес-логике для первого объекта.

person Ladislav Mrnka    schedule 03.05.2011
comment
Я не могу сломать существующие таблицы. В этом случае я буду придерживаться защищенного свойства, чтобы скрыть избыточное свойство от пользователей. - person Danny Varod; 04.05.2011