https://stackoverflow.com/questions/40443409/postgresql-in-operator-performance-list-vs-subquery почему in тормозит вопрос исключительно его реализации. any который делает тоже самое не тормозит

Что такое any? Я не знаю такого

Какая-то хитрющая оконная функция?

Из вот этих вот lag, lead и всего этого добра?

оно там в ссылке `where i = any (values (500),(501),(502),(503),(504),(505),(506),(507),(508),(509),(510),(511),(512),(513),(514),(515),(516),(517),(518),(519),(520),(521),(522),(523),(524),(525),(526),(527),(528),(529),(530),(531),(532),(533),(534),(535),(536),(537),(538),(539),(540),(541),(542),(543),(544),(545),(546),(547),(548),(549),(550),(551),(552),(553),(554),(555),(556),(557),(558),(559),(560),(561),(562),(563),(564),(565),(566),(567),(568),(569),(570),(571),(572),(573),(574),(575),(576),(577),(578),(579),(580),(581),(582),(583),(584),(585),(586),(587),(588),(589),(590),(591),(592),(593),(594),(595),(596),(597),(598),(599),(600)) `

Хера а так можно что ли?

в постгресе много что можно. даже jsons парсить

Ну круто, да.

Но это именно тот вопрос, который я и обсуждаю

in (a, b, c) — фуфел и хрень

Потому что тут N параметров

И везде это будет работать плохо без ухищрений

О, я нашёл реализацию: https://stackoverflow.com/questions/50669574/ef-core-find-method-equivalent-for-multiple-records

any (array (a, b, c)) — хорошо, потому что тут один параметр-массив.

О, я нашёл реализацию: https://stackoverflow.com/questions/50669574/ef-core-find-method-equivalent-for-multiple-records

Но она супер медленная

in (a, b, c) — фуфел и хрень

точнее его конкретные реализации. согласись что any от него практически не оличается

точнее его конкретные реализации. согласись что any от него практически не оличается

Ну все его конкретные реализации

Везде

Я пока не видал хорошей реализации-то

О, я нашёл реализацию: https://stackoverflow.com/questions/50669574/ef-core-find-method-equivalent-for-multiple-records

Надеюсь, ты код из поста не собираешься использовать в хайлоаде

Выглядит прям нуваще ужасно

В смысле, что там много чо можно закэшировать и сделать более типобезопасно

Да, конечно, сам конкретный экспрешен с замкнутым списком идентификаторов тебе в любом случае придётся аллоцировать, это ок

Но всё остальное можно закэшировать норм

Выглядит прям нуваще ужасно

Да, я вижу

Да, конечно, сам конкретный экспрешен с замкнутым списком идентификаторов тебе в любом случае придётся аллоцировать, это ок

Оно медленно?

Потому что F# один хер не поддерживает LINQ

А QueryBuilder не с IQueryable работает?

Оно медленно?

Что медленно?

А QueryBuilder не с IQueryable работает?

Вроде да, под копотом он делает LINQ-запрос.

Что медленно?

Создание экспрешена с замыканием

Создание экспрешена с замыканием

С чем сравниваем?

Ну ты же понимаешь, это просто выделить память

С чем сравниваем?

Ну без создания эксрпешена)

А, ну так да, он же не компилирует его по сути

Ну без создания эксрпешена)

Создать экпрешен — примерно в бесконечное количество раз медленнее, чем не создвать экспрешен

Соре, я понимаю, что ответ быссмысленный, но не могу дать ничего лучше

Соре, я понимаю, что ответ быссмысленный, но не могу дать ничего лучше

Я щас разбираюсь как Find работает в EF

Это пздц

Я щас разбираюсь как Find работает в EF

Расскажешь потом нам?

Ещя разберусь

Я уже потерял нить :D

Мне всегда было интересно, отличается ли Find(id) от .Where(x => x.Id = id).First()

Возможно, кэши по-разному отработают?

О, я нашёл реализацию: https://stackoverflow.com/questions/50669574/ef-core-find-method-equivalent-for-multiple-records

Нормальны бы человек заюзал это и не парился

Нормальны бы человек заюзал это и не парился

Там же просто через рефлекшометр вызывают Contains?

Почему не писать в запросах сразу Contains?

Там же просто через рефлекшометр вызывают Contains?

Там экспрешн генерируют через Contains

Там экспрешн генерируют через Contains

Там генерируют экспрешен с контейнсом, так?

Да

Но грязновато

Ну вот а чо в запросе сразу не написать контейнс?

Мне всегда было интересно, отличается ли Find(id) от .Where(x => x.Id = id).First()

первый работает так: ищет в контексте, если не находит - обращается в базу. .Where(x => x.Id = id).First() - всегда обращается в базу

Ок, я так и думал

Ну вот а чо в запросе сразу не написать контейнс?

Я хочу GenericRepository :)

Я хочу GenericRepository :)

А я не хочу, имхо это дурной паттерн

Хочется леща прописать

первый работает так: ищет в контексте, если не находит - обращается в базу. .Where(x => x.Id = id).First() - всегда обращается в базу

Только не First, а FirstOrDefault

Кстати, можно немного проще написать, типа так: items.Where(x => ids.Contains(x.Id))

проще это использовать. проблема-то никуда не девается в FindMany

А я не хочу, имхо это дурной паттерн

Ты про паттерн репозиторий?

Ты про паттерн репозиторий?

Нет, про генерик репозиторий

Нет, про генерик репозиторий

А чем плох?

«Репозиторий, который подойдёт всем»

Нет, не подойдёт.

В половине случаев это просто лишний код и обуза

А во второй половине случаев его всё равно недостаточно

Так зачем нам нужен токой генерик?

Так реализация репозиториев же одинаковая для всех

Нет, не одинаковая.

Нет, не одинаковая.

Поясни

DbSet<T> - реализация репозитория

Для ~70% репозиториев мне не нужно искать объекты по id

Для ~95% репозиториев мне не нужно искать объекты по списку id

Плюс это и неэффективно, на самом деле

Для ~95% репозиториев мне не нужно искать объекты по списку id

Ты просто GraphQL апи не писал)

В моём мире каждый запрос вручную тюнится и поддерживается

И, да, GraphQL я не писал, и я вижу, для чего там могут потребоваться генерик репозитории, окей

В моём мире каждый запрос вручную тюнится и поддерживается

Ну в моём тырыпрайз мире вообще нет репозиториев 🌚

Вот только я в GraphQL не совсем понимаю прикол, получается вместо одного запроса с JOIN мы просто делаем 100500 запросов

Или там вся надежда на HighLoad и кэши DataLoader'a?

Graphql удобно с т.з. фронта, но бэк на нем страшноват, конечно

Или там вся надежда на HighLoad и кэши DataLoader'a?

Не знаю таких, и не вижу, какая надежда на них может возлагаться.