Интересные моменты работы LINQ to SQL. Опять

[datacompboy]

А почему форк, а не пуш в апстрим?

[IharBury]

1. У LINQ-to-SQL нет собственного upstream. Он доступен только как часть Microsoft .NET Reference Source (https://github.com/Microsoft/referencesource).
2. Изменения, которые мы вносим, направлены не на развитие самого LINQ-to-SQL, а на плавный и безболезненный переход больших enterprise проектов с LINQ-to-SQL на Entity Framework.

[mayorovp]

Это очень печально по нескольким причинам: это не документировано никак (на сколько мне известно), из-за этого иногда падают OutOfMemory (так как вычитанные сущности уже никогда не покинут контекст, хотя код будет выглядеть так, как будто ты вычитываешь анонимные объекты, которые будут быстро собираться GC)

Эта проблема решается использованием 1 контекста на 1 единицу работы — все «скрытые сущности» прекрасно собираются сборщиком мусора вместе с самим контекстом.

Заодно при этом решается проблема «отравления контекста» — это когда в контекст добавляется некорректная сущность — после чего все последующие вызовы SubmitChanges кидают исключения, пытаясь добавить эту сущность в БД снова и снова.

[Youkai]

Контекст у нас свой на каждую транзакцию.
Тут проблема скорее не в том, что сущности никогда не покинут контекст, а в том, что по коду даже не видно, что они в контекст загружались.

Например, если выполнении следующего запроса

var activeActionTemplates = modelContext.Repositories.Get<ActionTemplateRepository>().Items
    .Where(at => at.EffectiveStartDateTimeUtc <= DateTime.UtcNow)
    .Where(at => at.EffectiveEndDateTimeUtc > DateTime.UtcNow)
    .ToArray();

все ActionTemplate'ы загрузятся в память, так как EffectiveStartDateTimeUtc и EffectiveEndDateTimeUtc не мапятся на SQL. Если таких сущностей в базе много, то может даже упасть OutOfMemory, хотя по коду кажется, что мы вычитываем только небольшой массив данных.