ну по идее да, если просто сделать БД с новым именем ?

Ребята, а как правильно делать запрос с Ecto.Query, Так чтобы брать строку из таблицы, и количество его детей. Пытаюсь делать так. query = from(r in Room) |> preload(:messages) |> join(:left, [r], m in assoc(r, :messages), m.receiver_id == ^user.id) |> group_by([r], r.id) |> select([r, m], {r, count(m.id)}) Пишет argument error

Детей строки?

его - запроса?

Ну например у меня, room имеет много messages

хочу брать room и количество сообщений в нем

Preload и join точно не должны быть вместе

у message есть room_id?

у message есть room_id?

Ну конечно

Как иначе то?

Там receiver_id

Написано

room_id тоже есть, assoc(r, :messages) он добавляет по room_id. Просто дополнительно еще одно условие добавил про receiver_id

Какая то хрень в запросе, вот реальная

Тебе надо строку или все строки?

Зачем это условие с receiver?

да

да

Это ты подтвердил, что хрень :)?

и то и то)

Условие с receiver чтобы отфильтровать сообщения этого рума

если убрать все равно ошибка

from(m in Message, group_by: :room, select: {m.room, count(m.id)})

не такое надо?

from(m in Message, group_by: :room, select: {m.room, count(m.id)})

Только ещё where m.receiver_id == ^user_id

И возможно нужен прелоад

Но это неточно

я пока не понял зачем тут receiver_id, если только сгруппировать по room

или "выбрать количество сообщений этого receiver в каждой room"?

или "выбрать количество сообщений этого receiver в каждой room"?

да

или "выбрать количество сообщений этого receiver в каждой room"?

Походу в параметрах передаётся пользователь для которого делается выборка

from( m in Message, group_by: :room, where: m.receiver_id == ^user_id, select: {m.room, count(m.id)} )

предположение, не запускал)

Мне кажется m.room не сработает без прелоада

Но я тоже не запускал

С прелоадом и без прелоада пишет Message.room` in select does not exist in the schema in query если джойнить и группировать по r.id, все нормально работает

ну там room заменить на room_id наверн

не помогло, пишет column "r1.id" must appear in the GROUP BY clause or be used in an aggregate function

ну если писать room_id вместо room

еще бы кто-нибуль гист запилил с рабочим примером)

https://gist.github.com/UA3MQJ/d7572544d0922f0b9654c12ed3964c50

вот это респект!

по картинке видно, что отдельные процессы вызывают долгие и быстрые calls и все получают результаты. но долгие calls не блокируют вызовы быстрых

я чуть позже гляну и обязон отпишу ?

я чуть позже гляну и обязон отпишу ?

ага. единственное, что не стоит забывать, что по умолчанию у call таймаут 5 секунд.

Кто-то использовал библиотеку locker?

ага. единственное, что не стоит забывать, что по умолчанию у call таймаут 5 секунд.

Твоя правда, оно не блокирует быстрые call'ы и всё "считает" до 8 ) единственный момент, который я не понял это вот тут https://gist.github.com/UA3MQJ/d7572544d0922f0b9654c12ed3964c50#file-tst_gen-ex-L36

обычной же кейс такой, что тебе надо посчитать что-то долгое (твой spawn), и вернуть результат именного этого spawn

а ты тут как бы жульничаешь, заранее делая +1 в noreply

ну в стейте я храню номер запроса. и его возвращаю

а в репли мог бы возвращать {номер запроса, результат вычисления}. сам пример кода именно чтоб показать отложенный репли.

осмысленности в его действиях особой нет.

угу, я просто пытаюсь придумать примеры из жизни где так удобно юзать) тут получается "теряется" механика защиты state аля mutex'ом...и если запустить 4 таких long'a то они каждый перетрут результат предыдущего т.к. spawn запускается на старом state (если у тебя результат long'a зависит от изначального state)

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

угу, я просто пытаюсь придумать примеры из жизни где так удобно юзать) тут получается "теряется" механика защиты state аля mutex'ом...и если запустить 4 таких long'a то они каждый перетрут результат предыдущего т.к. spawn запускается на старом state (если у тебя результат long'a зависит от изначального state)

не перетрут. они в любом случае выполняются последовательно. и каждый вызов по очереди увеличит ID запроса и сохраняет новое значение в стейт. а в spawn передается его текущее значение. это ж не глобальные переменные.

сначала я хотел посложнее пример сделать. но решил для начала вот такой по проще, где вычислений нет, а просто показано, как оно не блокируется. вот ошибся )

Можно сделать что-нибудь типа: к gen_server-у приходят запросы на какую-то долгоиграющую операцию, мы запоминаем запросивщего и параметры с которыми он запросил и инициируем операцию. Все новые запросы с уже запомнеными параметрами просто запоминаем. Когда вычислим результат ответим сразу всем.

да. вот такой пример хотел с самого начала сделать

угу, я просто пытаюсь придумать примеры из жизни где так удобно юзать) тут получается "теряется" механика защиты state аля mutex'ом...и если запустить 4 таких long'a то они каждый перетрут результат предыдущего т.к. spawn запускается на старом state (если у тебя результат long'a зависит от изначального state)

ну к примеру gen-server содерждит пул потоков воркеров. в его стейте хранится загруженность воркеров. когда к gen-server приходит запрос мы в стейте смотрим у какого воркера сколько запросов, и выбираем тот у которого их наименьшее количество и пуляем ему запрос, а в стейт для него записываем count +1. Когда воркер выполнит запрос он пошлет клиенту ответ а серверу запулит сообщение что он выполнил задачу и тот сделает для него count - 1. Таким образом мы получаем сервер синхронно выполняющий запросы и балансирующий загрузку воркеров

да можно еще какие-нибудь интересные штуки придумать, а самое главное тут что такой механизм работы доступен "из коробки"

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

> gen-server содерждит пул потоков воркеров а кто контролирует их лайв цикл?

тот же spawn, который "long" может отстрелиться, и клиент ничего не получит?

или вот еще. к примеру у нас есть БД в ETS. При этом нам нам надо сделать запись сразу в несколько таблиц по определенным айдишникам. Чтобы не нарушить консистентность, мы пулям запрос в gen-srver, тот хранит в стейте имена ETS таблицы и у каждой таблицы список id записей, которые сейчас заняты в каких то операциях. Если при запросе сложной операции (транзакции) сервер не нашел нужных нам айдишников в списках соотв таблиц, то запускает нужную нам операцию и ids кладет в список соотв таблицы и в стей . Если придет любой другой запрос в котором нужны эти же ids то сервер посылает этот запрос сам себе в handle_info - откладывая его пока "не освободятся ids"

жизненный пример: есть орграф для обработки данных, где каждая вершина работает асинхронно, но запустить следующую можно только, когда все предыдущие отработают. каждая вершина – это генсервер, который по завершении шлёт депешу следующему. тот в свою очередь хранит в стейте какие из инцидентных вершин уже отработали. когда окажется, что все – запускает обработку.

> gen-server содерждит пул потоков воркеров а кто контролирует их лайв цикл?

ну он не может быть для них супервизором?

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

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

думаю можно сделать супервизор который запустит пул потоков и сам сервер и передаст серверу этот пул, ну или еще как... думаю когда припрет все можно сделать ))))

жизненный пример: есть орграф для обработки данных, где каждая вершина работает асинхронно, но запустить следующую можно только, когда все предыдущие отработают. каждая вершина – это генсервер, который по завершении шлёт депешу следующему. тот в свою очередь хранит в стейте какие из инцидентных вершин уже отработали. когда окажется, что все – запускает обработку.

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

изобретаем, но отдельно от логики

вот как раз для пулов, врооде бы, и есть пулбой. он для всего. а для сокетов есть ranch. ну и в принципе все вот эти count+-1 это велосипед. для параллельных запросов в эликсире есть Flow. целью было показать отложенные reply, а для чего - это уж каждый сам решает.

ну или так

вообще я тут Лапшина почитал - он там использование call применяет в качестве паттерна back pressure для ограничения поступления данных, чтоб задержать отправителя на call'е пока гс думает. ну и в этих целях может пригодиться как раз вот этот отложенный reply. но в целом, имхо, это всё выглядит как хак. Иожев Валимов для back pressure запилил для нас GenStage и Flow

поэтому, я и спросил, кто-то пользует или нет ))) оказалось, что пользует

жизненный пример: есть орграф для обработки данных, где каждая вершина работает асинхронно, но запустить следующую можно только, когда все предыдущие отработают. каждая вершина – это генсервер, который по завершении шлёт депешу следующему. тот в свою очередь хранит в стейте какие из инцидентных вершин уже отработали. когда окажется, что все – запускает обработку.

но вроде это можно решить просто cast'ую следующий генсервер? Раз они "по-цепочке" работают, то когда cast выполнится внутри одного генсервера, то он вызовет cast следующего и т.д. до конца?

да, так и есть

или можно попробовать сделать аля звезду - когда в центре есть генсервер, который инициирует обработку вершин, а ответ от них получается через отложенный :gen_server.reply (как Alexey показывал)..а получив ответ инициирует обработку следующей вершины и т.д...тем самым генверсеры вроде как друг об друге знать не будут лишнего...хотя это всё решение "на словах")

можно просто на уровень логики это делегировать

не нравится мне эта Светочка

в кристал чатик тоже пришла...

*удалил*

не нравится мне эта Светочка

зобанил

и в чатик по Go

и в Python beginners

И в скалу

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

Привет, господа. Есть тут кто?

доброго времени.

Я вообще из мира джаваскрипта и тут мне мой товарищ-бэкендщик накидал своих штук, а я смотрю и ничего не понимаю.

Вы таких с вопросами сразу баните или можно попробовать поинтересоваться? Возможно именно Вы сможете мне помочь :)

задавай...

Есть штука которая аплоадит на s3 файлы и возвращает линк на скачивание. Эликсир мне возвращает чисто хэш и типо все клево. Все это работает.

Случаи: 1) Человек зааплоадил файл, перешел по ссылке и даунлоад начался через 10 секунд 2) Человек скопировал ссылку и открыл ее в новой вкладке, даунлоад начался через 10 секунд

Во-первых из этого не реализовано то, что даунлоад начинается через 10 секунд. Я собирался показывать на фронте страницу и потом просто делать ручками редирект по таймеру.

Первый случай так реализовать получится. С этим проблем нет.

Но дело во втором случае: если я сразу перейду по нужной ссылке, оно сразу начнет аплоад и не покажет даже страницу

Сейчас это выглядит вот так, насколько я понял: