То ли задачка то ли оказалась нетривиальной, то ли я где-то сильно затупил.

Вот запрос на SQL



У покупателя может не быть заказов, либо у заказов может не быть товаров, в этом случае я должен получить только поля покупателя и NULL для полей заказа и товара.

При попытке написать на Linq2EF я либо получаю NullReferrenceException при попытке второго джойна (так как нет объекта, из которого надо достать id), либо отбор несколькими запросами, при этом внутренних таблиц не производится фильтрация в БД, то есть на клиента приходят все заказы и все товары и только потом фильтруются.

В общем, как написать этот запрос для EF?

Сначала замутил что-то такое:


Потом такое:

в первом накосячил, когда пример делал:

hVosttа чё, нету навигационных полей, типа customer.Order? если есть, решаетсяПоля есть (не customer.Order, а customer.Orders разумеется), но с ними совсем не взлетает. Гуглил, как я понял проблема сгенерить проекцию с нормальными джойнами, не получив N+1 запросов к базе, не решена (точнее решена в каком-то очень частном случае и только с одним уровнем джойна). Может ты подскажешь как?

hVosttпохоже на то, что запрос материализуется сразу, а не транслируется в SQLНет, в первом случае я получаю ровно один запрос к базе. Во втором N-1 (по количеству вложенных уровней), что тоже устраивало бы, только нижние уровне не фильтруются на уровне запроса к БД.

Code First, EF Core

Petro123нет логики в запросе.не ищи логику, это пример, а не рабочий код, хочешь - в зайцев перепиши.

hVosttА, Core... понятно. Именно EF он ещё очень сырой, при чём настолько, что практически неюзабельно. Половина проекций не работает, группировка? давай досвидания... Миграции, как повезёт вообще, да и не работают толком как в EF 6.Ну интересно, они что, с нуля его писали? Я полагал, большинство кода взято все-таки с EF6. Ну и не могу же я юзать EF6 под ASP.NET Core.

Опять же - задача-то абсолютно тривиальная - два Left Joina. Ну а как это решается в EF6?


hVosttсоветовал бы уйти на другой провайдер, в версии EF Core от него пользы как от козла молока. Ещё годик другой может.вот это не совсем понял

Petro123А что ее искать, если запрос не к той сущности.
Запрос должен быть логичен, а не джойнить все подряд.
Логично?Не логично, я не буду тратить время, расписывая тебе реальную бизнес-модель полдня. Есть конкретная выборка, которую я хочу получить - два вложенных отношения один-ко-многим, названия сущностей можешь свои подставить, если тебя коробит.

Petro123Сторону Многие сворачиваем через count?Да блин, ничего не сворачиваем, я же пример написал на SQL - ты видишь там Count?
В итоге мне нужно загрузить иерархическую модель в дерево.
Я конечно могу написать это ручками тремя запросами послойно, если нет другого выхода, но странно, если его нет.

Petro123Т.е. from Заказы!Какая разница между
FROM Заказы RIGHT JOIN Покупатели и
FROM Покупатели LEFT JOIN Заказы
Если тебе не нравится LEFT JOIN перепиши на RIGHT JOIN - суть не поменяется
Базовая таблица - Покупатели в данном случае

hVostt https://github.com/ServiceStack/ServiceStack.OrmLite

Поддерживает Core в полный рост, умеет то, что ты хочешь.Спасибо. То есть ты имел ввиду - заменить сам ОРМ (меня смутило слово провайдер).

Но сейчас так просто прыгнуть не получится, нужно будет переписывать репозиторий, в котором много чего. С EF на Core переделок было минимально, на вот на другой ОРМ перейти щас нет времени.

А что там с миграциями у вас было, не помнишь? Пока тьфу-тьфу, не споткнулся.

Petro123Прочитал счас что linq не поддерживает outer join )))Может тебе сначала стоит литературку там почитать, учебники, опыт какой-никакой приобрести, а потом уже консультировать на форуме? А то в каждом топике затычка, а толку в каждом из них - ноль.

hVosttДа, пишут с нуля. Потому что решили покрыть не только реляционку, но и NoSQL тоже. И архитектуру внутри решили поменять в корне. Отсюда все грабли :)Ну в общем, спасибо, что обратил моё внимание на это, я-то исходил, что в EF Core может быть только больше функционала, но никак не меньше, соответственно, были неверные посылы. Сейчас появилось немного времени, поковырялся уже с новой точкой зрения и откопал две вещи:

1) В EF Core нет ленивой загрузки (!)
2) При применении ThenInclude есть косяк в VS - неверно работает Intellisense, соответственно, это меня тоже сбило с толкуCurrent versions of Visual Studio offer incorrect code completion options and can cause correct expressions to be flagged with syntax errors when using the ThenInclude method after a collection navigation property. This is a symptom of an IntelliSense bug tracked at https://github.com/dotnet/roslyn/issues/8237. It is safe to ignore these spurious syntax errors as long as the code is correct and can be compiled successfully.

В итоге можно просто написать через навигационные свойства


Все равно через ж, потому что проекция не работает, точнее сгенерит N*M+1 запрос, но хотя бы можно материализовать и потом спроецировать. Запрос к БД при этом тоже интересно, получается три запроса -
Customers
Orders Inner Join Customers
Goods InnerJoin Orders Inner Join Customers
И фильтр пробрасывается во все три запроса, в результате получается-таки LEFT JOIN.
Ну это хотя бы не N*M+1 запрос.
И группировка не работает.
Да, полное овно.
Я офигел, честно говоря. Был же продукт. Ну пилили бы другой с другим названием с нуля, зачем ломать старый-то, революционеры хреновы.

hVostt https://github.com/ServiceStack/ServiceStack.OrmLite

Поддерживает Core в полный рост, умеет то, что ты хочешь.Посмотрел овервью, да, похоже вещь сделана для людей и руками, а не жо-ой.

Даже есть SelectFilter на таблицу, то что я руками пилил в своем RepositoryBase поверх EF.

Ты вообще с этой штукой работал, понравилось?

И я правильно понял:
1) Аналога трекера там нет, то есть встроить дополнительную модификацию объектов перед общим сбросом в БД не получится?
2) Про автоматическое изменение схемы БД тоже ничего толком не нашел - все миграции ручками?

hVosttВо-вторых, это редкий случай, когда ORM содержит поддержку DDL, так что можно абстрагироваться от СУБД и писать миграции на более высоком уровне.А можешь пояснить? Тут не догнал.

hVosttНу чё, нашли фатальный недостаток, нормально :)Да ну, тут ты гонишь - его же они сами и писали

А данные?

hVosttShocker.ProА данные?

Ну Create/Update... )) Ты же про посев?Я вообще про апгрейды, развертывание в том числе.

Если в EF я просто занимаюсь разработкой могу несколько раз поменять модель и когда пришло время, миграция сгенерилась автоматически, то тут я должен менять модель и сам ручками параллельно делать как миграцию (следя за тем, чтобы она оставалась синхронной с моделью), так и поддерживать версионность схемы БД, если я не работаю напрямую с продакшен базой, а предполагаю, что схема должна обновляться у клиента в автоматическом режиме. Так?

Petro1231) как решил что ленивая не работает? https://docs.microsoft.com/en-us/ef/core/querying/related-data
Petro1232) базовую таблицу from не пробовал сменить??
Petro1233) запросы сразу к трем таблицам Много ко Много вполне могут допилить позже.
Это мне пока не требовалось от Core, с другой стороны, я и не использовал М:М возможности и в EF.NET, создавал таблицу связок вручную.Petro123Они не каждодневные и больше не к ОРМ идут а к отчетникам и аналитикам.Теоретик, блин

hVosttВсё верно. Все миграции писать ручками, завести служебную таблицу миграций (чтобы поддерживать схему БД), написать механизм миграций.А где смайлик?
А есть какая-нить ОРМ, которая поддерживает автоматическую генерацию миграций, помимо EF?

Petro123,

Все твои сообщения говорят о том, что дальше Hello World с БД, SQL и данными тебе работать не приходилось, так что извини, отвечать на тво бредовые вопросы желания никакого нет. Если ты хотя бы примеры кода приводил, я бы мог указать на твои ошибки, но ты занимаешься просто бла-бла. Было бы пофиг, если бы ты свои флудом не занимал бы больше половины топика, забивая нормальный диалог. Поэтому постарайся просто помолчать, если уж совсем не терпится, напиши код, проверь его, тогда уже можно будет о чем-то говорить.