Тут вопрос такой. Как в IQueryable сделать такое:
Func<User, string> identifier = x => x.id;
users.Where(x => ids.Any(id => identifier(x));
Таким образом он не хочет работать, вот мб как-то передать Expression<Func>?
@fvnever ты обещал рассказать)
Nikolay
Vladislav
https://twitter.com/matthewwarren/status/1108041540847497217?s=12
Ayrat
так работает же
Ayrat
да я каждый день пользуюсь
Ayrat
и это только я
Ayrat
понимаю
Ayrat
в райдере IL вьюер встроили
Ayrat
я пока не оценил
Ayrat
(не понял как его запустить)
Ayrat
но наверное он работает
Ayrat
я вообще там 90% кнопок не понимаю, звездолёт какой-то
Ivan
Тут вопрос такой. Как в IQueryable сделать такое:
Func<User, string> identifier = x => x.id;
users.Where(x => ids.Any(id => identifier(x));
Таким образом он не хочет работать, вот мб как-то передать Expression<Func>?
у тебя то, что в скобочках у Any должно булеан возвращать, а не строку ids.Any(id => identifier(x))
т.е. оно должно быть типа Expression<Func<TSource,bool>>
Ivan
вот так заработает?
`Expression<Func<User, string>> identifier = x => x.id;
users.Where(x => ids.Any(id => identifier(x)==id);`
x
продолжая тему гейм контроллеров
x
там гугл выпустил контроллер
x
Stadia
x
https://www.theverge.com/platform/amp/circuitbreaker/2019/3/19/18273461/google-stadia-cloud-gaming-service-controller-hands-on-gdc-2019
Nikolay
вот так заработает?
`Expression<Func<User, string>> identifier = x => x.id;
users.Where(x => ids.Any(id => identifier(x)==id);`
Не заработает. Там же не Func<>, а Expression<Func<>>
Nikolay
Не заработает. Там же не Func<>, а Expression<Func<>>
Возвать можно только так:
identifier.Compile()(x)
Nikolay
Что не катит для EF
Dr. Friedrich
Возвать можно только так:
identifier.Compile()(x)
Кратко: делайт свой комбинатор экспрешенов
Dr. Friedrich
Если у тебя F#, то тебе даже повезло
Dr. Friedrich
Потому что F# один хер не поддерживает LINQ
Dr. Friedrich
Так что тебе в любом случае надо будет писать генератор экспрешенов
Dr. Friedrich
По сравнению с C#-пеонами ты в преимущественном положении
Nikolay
Но я пишу на C# :(
Dr. Friedrich
Почему это важно?
Nikolay
Ну потому, что по сути нужно на каждый вызов генерировать экспрешн, видимо
Nikolay
Чтобы передавать туда параметр
Nikolay
Через замыкание
Dr. Friedrich
А нельзя ли без замыканий переделоть, а?
Dr. Friedrich
Ну и собстно а с чем мы сравниваем?
Dr. Friedrich
Ты ж понимаешь, что C#-конпилятор будет делать то же самое?
Dr. Friedrich
Это плохо, да, но это примерно одинаково плохо, вне зависимости от генератора.
Nikolay
Ну вообще я хочу написать Generic Repository, в котором нужно будет указывать в аргументе id
Nikolay
Хотя, я придумал как лучше сделать можно
Dr. Friedrich
.FindByIdAsync
Nikolay
Нужно IN по сути
Dr. Friedrich
Чего несколько?
Dr. Friedrich
А
Nikolay
В монге есть такое
Dr. Friedrich
Потому что это очень плохо работает на всех уровнях
Dr. Friedrich
Плохо параметризуется, плохо планы запросов персистятся, вообще всё плохо.жпг.
Dr. Friedrich
Прям ну ваще неудачный оператор запроса
Dr. Friedrich
Плохо спроектированный.
Dr. Friedrich
Тут вопрос такой. Как в IQueryable сделать такое:
Func<User, string> identifier = x => x.id;
users.Where(x => ids.Any(id => identifier(x));
Таким образом он не хочет работать, вот мб как-то передать Expression<Func>?
Ну а воще, если у тебя уже есть экспрешены, то можно их разобрать и пересобрать в нужном виде
Dr. Friedrich
Там визитор в них суёшь
Dr. Friedrich
А что у них общего с джоином?
Dr. Friedrich
Две буквы? :)
Pavel
пересечение множеств
Dr. Friedrich
Не понимаю
Dr. Friedrich
Синтаксис другой, проблемы ну ваще другие, варианты использования другие
Dr. Friedrich
Ну и перечисленных мной проблем нету, кажется
Dr. Friedrich
Если ты не хочешь запараметризовать имя таблицы в джоине, конечно. Тогда есть проблемы частично
Dr. Friedrich
Но и то, планы запросов в любом случае у джоина будут персиститься нормально, потому что вариантов таблиц для джоина у тебя небольшое количество
Dr. Friedrich
А вариантов, чо можно засунуть в in, и сколько там параметров — ну, условно очень большое количество :)
Pavel
все что засовывается в ин можешь считать просто таблицей из 1 столбца
Dr. Friedrich
Я-то так могу считать
Dr. Friedrich
Но что делать с перечисленными проблемами?
Dr. Friedrich
Как мне параметризовать это?
Dr. Friedrich
Как мне план запроса нормально обрабатывать?
Dr. Friedrich
Вернее, я-то этого не делаю, но как СУБД будет это нормально делать?
Dr. Friedrich
В общем, я могу и тыквой этот ин считать, или я могу считать, что его не существует
Dr. Friedrich
Но от того, что я буду что-то там считать, реальные проблемы никуда не денутся :)
Dr. Friedrich
Если бы в SQL были параметры-массивы или списки, которые можно засунуть в in @myмассив — то проблема бы самоликвидировалась.
В некоторых СУБД такие параметры есть, но я не видал, чтоб их можно было без костылей использовать в in.
Nikolay
Nikolay
Точнее оно преобразуется в IN (1,2,3,4)
Nikolay
Кстати, можно немного проще написать, типа так:
items.Where(x => ids.Contains(x.Id))
Pavel
https://stackoverflow.com/questions/40443409/postgresql-in-operator-performance-list-vs-subquery
почему in тормозит вопрос исключительно его реализации. any который делает тоже самое не тормозит