B
Size: a a a
2020 January 24
DP
один и тот же экземпляр же будет
Это ещё не значит что будет одна транзакция
B
Это ещё не значит что будет одна транзакция
но наверное в доках было бы написано об этом?
DP
но наверное в доках было бы написано об этом?
Что написано?
DP
По умолчанию контекст не использует транзакции
B
Что написано?
ну я имею ввиду в доках бы упомянули бы это наверное.
Там же рассказано как объединить транзакцию между несколькими экземплярами? Написано.
Значит для одного экземпляра - 1 транзакция
Там же рассказано как объединить транзакцию между несколькими экземплярами? Написано.
Значит для одного экземпляра - 1 транзакция
DP
Ну и можно несколько транзакций делать одним контекстом. context.BeginTransaction()
DP
Наверное архитектурно лучше таки принять TransactionScope а не полагаться на lifetime контекста
B
Наверное архитектурно лучше таки принять TransactionScope а не полагаться на lifetime контекста
я тоже так думаю
2020 January 25
Dv
Подскажите, есть async Task метод в другой сборке, как мне дебаггером студии зайти внутрь этого метода? Бряку внутри поставить не могу, а step into заставляет дебаггер заходить внутрь Task.cs
Что значит "не могу"? Всегда поясняйте такие моменты!
Dv
Не вижу корреляции между нагрузкой на базу и автомиграциями. Никак от нагрузки не зависит
На нагруженных БД часто есть специальные люди, которые заведуют миграциями: вручную их просматривают и организуют поэтапное накатывание скриптов.
Поэтому таки автоматические миграции там, и правда, используются реже.
И это я говорю про настоящие автоматические миграции, а не про то, что этим словом названо в EF.
Поэтому таки автоматические миграции там, и правда, используются реже.
И это я говорю про настоящие автоматические миграции, а не про то, что этим словом названо в EF.
Dv
Есть миграция А - она меняет схему
Есть миграция Б - она меняет данные
Мне нужна миграция В которая меняет схему
Я хочу чтобы порядок был А В Б чтобы сначала сделать всю схему а потом все данные
Есть миграция Б - она меняет данные
Мне нужна миграция В которая меняет схему
Я хочу чтобы порядок был А В Б чтобы сначала сделать всю схему а потом все данные
Если честно, я не понимаю, как вы в таком порядке разрабатываете. А что, если в миграции В добавились новые обязательные колонки в таблицы, затронутые миграцией Б? Она же тогда не сработает. Будем иметь поломанный дев/стейдж к минимум.
Dv
в монгу и нет проблем с миграциями
Как это нет? Там тоже нужен мигратор, всё точно так же — ну разве что с транзакциями проблемы, да.
Dv
RavenDB. Мы ж в дотнет чатике всё таки.
Имхо слишком своеобразно работает, очень сложно использовать без event sourcing и не отстрелить себе всё на свете.