LelouchAntonariy,

AntonariyЧасто нужно из одной таблицы получить новые id, чтобы вставить их в другую

Достаточно присвоить значение свойству навигации, ID будет сам подставлен при вставке.Можно тынц на пример, где это делается?

LelouchM234,

А как он отличит что значение не указано от "указано null" или "указано 01.01.0001" ?Запретить null. А 01.01.0001 и не null вовсе.
LelouchМожет вы хотели чтобы эти значения в базу попали?Как правило потребность сделать дефолт не пересекается с потребностью сделать null в том же поле. Иначе смысл дефолта только во одном — возможности перезаписать его null'ом позже. Но с ходу я не могу придумать, к чему это можно присобачить. И потом, на такую редкую ситуацию не лениво и руками конструктор дописать.

LelouchAntonariy,

Вопрос в том как EF должен отличить состояние "присвоен null" или "присвоено 01.01.0001" от "не нужно указывать в запросе" ?Нужно, чтобы поля модели, имеющие дефолт и запрет на null, генерировались как Nullable(Of T). Тогда, если поле содержит null, то подразумевается дефолт, и оно исключается из вставки.

LelouchAntonariy,

1) это неудобно
2) А если поле Nullable само по себе, но имеет Default в базе?1) Это неубедительно. Неудобно может быть делать что-то. Это же наоборот, избавляет от необходимости делать кое-что.
2) Ну и делать то, что уже делается сейчас, как будто дефолтов не существует в природе.

МСУ4. Вопросы, пожелания :)?Запилить печеньки для тех, кто не хочет отвязываться от субд.

LelouchА во всех остальных случаях это вносит необходимость использовать .Value или .GetValueOrDefault(). Так же это мешает использовать сущности в качестве объектов бизнесс-логики.Без конкретных примеров все еще не убедительно. Не вижу необходимости, не вижу помех в использовании.

LelouchТам есть печенька в виде Database.ExecuteSqlCommand и т.д., нужно еще?Это не печенька, а не молотое зерно.

Не убедительно.

Не помните — пишите что хотите, никаких запретов тому нет, тем более что вы и так это уже делаете. А я помню и писать не хочу. Пусть компьютер пишет, он это быстрее делает. В конце концов в мастере обновления модели из базы можно вкорячить четвертую галку "(do not) use database defaults", чтобы не лишать любителей подуть на холодное их любимого занятия.

В одной из баз, на которую со временем будет натягиваться ef, более трехсот таблиц, в каждой есть дефолты, и в большей части не по одному. И вместо того, чтобы тынцнуть галочку, мне придется писать триста сраных конструкторов.

Lelouch,

У вас неиллюзорные проблемы с формальной логикой. Рассматриваем поле, имеющее дефолт, больше ничего, следите внимательно.

I. Ситуация, которую имеем сейчас:
1) EF ничего не знает о дефолтах.
2) Если ничего не делать и поле допускает null, то сохраняется null
3) Если ничего не делать и поле не допускает null, то при попытке присвоить null генерируется исключение. Чтобы обработать это исключение требуется п. 4
4) Если произвести дополнительные операции (создать конструктор, прописать не null значения), то сохранится то, что прописано в конструкторе.

II. Чего хочется.
1) EF знает о существовании о дефолтов.
2) Если ничего не делать и поле допускает null, то сохраняется null
3) Если ничего не делать и поле не допускает null, то null исключается из операции вставки. В базу попадает прописанный в ней же дефолт, исключение не генерируется. Пункт 4 не нужен.
автор для не-nullable полей требует дополнительных операцийВы в своем уме, какие дополнительные операции? Пересчитайте пункты.

LelouchИ что даст эта опция?
1) Опция называется "Use database defaults"
2) При ее выключении реализуется I.
3) При ее включении реализуется II.

Lelouchкривое до безобразияА вот степень безобразия хотелось бы рассмотреть подробнее (остальное, как мы видим, ни о чем). Операция обновления в случае II. Представим самый трэш и адъ; с клиентской стороны кодит на js классический ССЗБ и умудряется в json прописать null в те поля, где их не было, ведь получен объект от сервера, который теоретически не мог вернуть null в тех полях, где не надо, потому запись получена непосредственно из базы, запрещающей в этих полях null. Фух. Что же произойдет? Если процедура обновления, создающая для этого объект модели (или его конструктор), принимает параметрами значения примитивных типов (маловероятно), то ошибка возникнет после десериализации на этапе вызовы этой процедуры/конструктора. Обычно же процедура получает анонимный объект, который приводит к соответствующему типу. В этом случае ошибку сгенерирует база.

В итоге "безобразие" II выливается в то, на каком уровне ССЗБ словит исключение при операции деления обновления на null. Прошу заметить: в случае операции обновления все отличие I от II лишь тем, что в I исключение сгенерируется конкретно в самой процедуре обновления, а не где-то еще.

МСУВ сферическом ORM это как кобыле пятое колесо.Поправил.

Ничего нового.

LelouchА в какой тип десереализуется JSON, если поля не nullable можно узнать? А то пока я вижу только 1 исход - при десерелизации получится исключение и на этом всё закончится.Это происходит в случае I. А в II JSON десериализуется в тип, в котором nullable свойство соответствует не nullable полю в базе. Я же с этого начал: 14330086 . Поэтому при десериализации ошибки не возникнет, она возникнет позже. Либо в базе, либо в самой процедуре, если есть еще какие-то манипуляции с этим полем перед сохранением и нет проверки на null. Но в любом случае это будет null exception, и я не вижу принципиальной разницы, на каком уровне она выскочит. Фактическое поведение немного изменилось, но формальное осталось прежним, не противоречащем правилам.

И напомню, эта ситуация исключительная, не способная возникнуть при минимальном наличии мозга: ну зачем насильно пихать null в обязательные поля, уже имеющие значения? А шанс попасть в продакшн у такого жирного косяка намного меньше одного процента.

А с другой стороны мне не надо писать триста сраных конструкторов. Или триста сраных вьюшек, в которых отфильтрованы default-поля. И скакать с субд на субд не надо. Хочу галку! :)