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

Отакже я не вижу, как GraphQL продуцирует у тебя 100500 запросов. Вроде бы основной поинт был как раз обратный.

Подумой! Возможно, ты что-то делаешь не так!

Вот вам история от человека, который точно что-то делает не так ↓

https://workplace.stackexchange.com/questions/131948/did-i-make-a-mistake-by-ccing-email-to-boss-to-others > My personal life is chaotic as my teenage son has autism/ADHD, I have depression, my teenage daughter has anxiety/depression and my wife has unspecified/undiagnosed mental health issues. She has mentioned feeling suicidal to me several times and gets no real help. The environment at home is physically and mentally chaotic, with frequent crises and lots of extreme stress.

И теперь мои проблемы мне не кажутся такими уж значительными…

Отакже я не вижу, как GraphQL продуцирует у тебя 100500 запросов. Вроде бы основной поинт был как раз обратный.

Ну смотри, например такая структура: public class Dealer { public int DealerId { get; set; } public ICollection<User> Users { get; set; } } Получается, мы тащим 100 Dealer'ов, и нам нужно сделать 100 запросов DealerId, если в GraphQL попросили получить юзера

> мы тащим 100 Dealer'ов, и нам нужно сделать 100 запросов DealerId Почему?

Хотя тут точно не уверен, может и DataLoader оптимизирует это и сделает один Fetch

Разве нельзя сделать запрос с тем же in?

Передайте что я протев такой фигни

Хотя тут точно не уверен, может и DataLoader оптимизирует это и сделает один Fetch

Т.е. получится такой запрос: select User.* from Dealer join User on User.DealerId = Dealer.DealerId where DealerId in (1,2,..100)

Т.е. получится такой запрос: select User.* from Dealer join User on User.DealerId = Dealer.DealerId where DealerId in (1,2,..100)

Ну допустим. Почему это плохо?

Ну допустим. Почему это плохо?

Если тащишь больше тысячи

Ну, если тебе нужно такую инфу загрузить, я не вижу более хорошего способа с точки зрения SQL.

Если тащишь больше тысячи

А зочем тебе больше тысячи?

Это уже клиент должен соображать

В оракле, например, больше 1000 по дефолту нельзя

Смешно

А зочем тебе больше тысячи?

Ну вот мы иногда генерируем огромные отчёты, и там сотни тысяч строк выгружается

Но таки да, есть такое

Ну вот мы иногда генерируем огромные отчёты, и там сотни тысяч строк выгружается

1. Это точно нужно делать через GraphQL?

Ну вот не точно)

2. Это точно проблема? Обычно отчёты генерируются не очень часто, и мб даже со специальной ридонли отчётной реплики

Ну этот вариант вообще применим, если GraphQL DataLoader работает так, как я думаю

Я не понел, при чём тут какой-то GraphQL DataLoader.

У тебя есть запрос, и тебе нужно по нему вернуть данные

Дальше уже не твоя забота. Если клиент запросил слишком овердофига — он сам и виноват

Ты можешь, конечно, попробовать с порога посылать нахер таких клиентов

Ну чтоб не досили сервер

Но ему в любом случае придётся у себя запрос переписать, если он не может его результаты переварить, так?

Но ему в любом случае придётся у себя запрос переписать, если он не может его результаты переварить, так?

Ну да, типа того

Тащить пачками

Это тот который 30 лет назад был Систем Шок 2?

Shellshock интереснее

Т.е. получится такой запрос: select User.* from Dealer join User on User.DealerId = Dealer.DealerId where DealerId in (1,2,..100)

@Dolfik если прямо вот так надо. я делал следующим образом: выгружал идентификаторы в темп таблицу и в contains обращался к ней: select * from User where User.Id in (select Id from #tempUser)

Исходники EF прекрасны

@Dolfik если прямо вот так надо. я делал следующим образом: выгружал идентификаторы в темп таблицу и в contains обращался к ней: select * from User where User.Id in (select Id from #tempUser)

Ну да, как вариант. Но EF вряд-ли додумается

ну, я его научил)

var ids = context.Users.Where(....).AsTemp(); var query = context.Dealers.Where(dealer => ids.Contains(dealer.UserId))

типа того

и притом это EF6

Прикольно, не знал даже про такое

моу код скинуть

правда это еще тот костыль

но работает

Кидай, мб пригодится)

https://gist.github.com/habib-sadullaev/7a733dbf28b8faca4e5fc777091fd3ab

и нужно заглушку для темповой таблицы сделать

ну, чтоб при ее появлении контекст мог ее увидеть

https://gist.github.com/habib-sadullaev/7a733dbf28b8faca4e5fc777091fd3ab

Хмм, а что за база у тебя?

ms sql

если ты об этом

Я вижу ты обычные таблицы используешь

Просто в оракле есть специально для этого временные таблицы, в mssql скорее всего тоже

Они даже на диск вроде не пишутся, просто в памяти лежат

ну, в еф6 без таких ухищрений не обойтись

я подозреваю, в еф-коре больше возможностей

Просто в оракле есть специально для этого временные таблицы, в mssql скорее всего тоже

ага

вот в нее и записывается

там спей база есть

TempDb

кажись

в ms sql

Не, там суть в том, что ты temporary создаёшь также, как и обычные

CREATE GLOBAL TEMPORARY TABLE {temp}(id NUMBER);

Типа так

а

в мс сиквеле по-другому

но суть таже

А в Oracle 18c можно сделать вообще таблицу на сессию

она в рамках одного соединения создается

и удалается автоматом

А в Oracle 18c можно сделать вообще таблицу на сессию

ну, вот она самая

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

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

Ток проблема, если переиспользовать подключения

ну, обычно, одно подключение на один запрос

так что не вижу проблемы

в зависимости от сценария, можно немного переделать в класс с IDisposable

и через using указывать скоуп

https://www.theverge.com/platform/amp/circuitbreaker/2019/3/19/18273461/google-stadia-cloud-gaming-service-controller-hands-on-gdc-2019

вообще классная штука. Надо, конечно, смотреть на монетизацию сервиса. А так уже все крупные игроки ударились в облачный гейминг. Сони. МС и вон теперь еще и Гугл. Интересно, как будет сони делать, ибо у гугла и МС есть уже давно свои сервера по миру, а вот у сони заметно меньше их. И Знаете что самое веселое? то что обланый гейминг уже был. Помню ах 2008-10 я был сказал, как раз когда выходил Crysis и все остально и все такие мы представим вам будущее облачный гейминг, где даже кризис пойдем на максималках. Я о том, что большинство новых идей в IT как то начинают работать только во второе пришествие. Аналогично с ВР.