Обновить
2
0
Александр@a_deb

Бэкендер

Отправить сообщение

Так же в приведенном выше случае нет проблем с точки зрения БД. Согласованность не нарушается.

Если выполнить сгенерированные EFC запросы не в EFC (а например на голом ADO.NET), то проблемы не будет.

Поэтому я не воспринял предупреждение из документации, как относящееся к внутренней логике EFC соединения детей с родителями, о чем собственно сказал в статье

  • While most databases guarantee data consistency for single queries, no such guarantees exist for multiple queries. If the database is updated concurrently when executing your queries, resulting data may not be consistent. You can mitigate it by wrapping the queries in a serializable or snapshot transaction, although doing so may create performance issues of its own. For more information, see your database's documentation.

Я согласен с вами по поводу проблем в применяемом подходе.

Передо мной стояла задача обновить EFC.
При обновлении я включил SplitQuery, так как без него были проблемы, и не видел в этом чего-то плохого, ведь я таким образом не менял поведение, которое было в EFC 2.0.

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

Дополню, что в нашем случае:

  1. задача отправки заказов в офисы прочитала заказы (Order)

  2. задача отправки заказов в бухгалтерию поменяла поле в Order

  3. задача отправки заказов в офисы прочитала блюда из заказов (DishInOrder) - вторым, разделенным запросом

И вышло так что в пункте 3 для некоторых заказов не подгрузился список блюд

В нашем случае выполнялись две плановые задачи:

  1. отправка опубликованных заказов в офисы

  2. отправка опубликованных заказов в бухгалтерию

Первая задача не модифицировала заказы, только читала.

Вторая задача выполняла изменение одного поля (ConfirmationId).

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

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

В EFC 2.0 проблем в таком кейсе не было.

В том же issue недавно появился новый пример, в котором не используется конструктор и соответственно не затрагивается материализация.

https://github.com/torutek/EfTest/blob/master/EfTest/EfTestContext.cs#L53

Но это тоже своеобразный хак

Ссылка на данный issue была приведена в статье и первый пример был взят от туда.

Со вторым примером столкнулись уже мы.

Подскажите что вам не понравилось в моделях? Я их взял из Контур.Кафе и существенно обрезал. Вы бы хотели видеть более абстрактные модели?

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

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Зарегистрирован
Активность