Можно выдумать презентер

Декоратор

Ещё хуй знает что

ну не будешь же ты выкачивать с бд все 1000 комментариев, чтобы потом разбить их на страницы по 100?

Я - нет

ну это больше абстрактное “ты"

никто не будет

это все холивар конечно же, но банально, если коментариев будет много и/или у них появится пагинация, нужно будет все равно делать логику в контексте, нет?

всё ровно по-прежнему. получение данных - контроллер и контекст, подготовка к выводу - вью

Например, кол-во комментов на странице это-таки Enum.count(comments) в контроллере либо вьюсе

но уж никак не контекст

Контроллер нагружать ненужными данными

Нафик надо )

Вьюха

всё ровно по-прежнему. получение данных - контроллер и контекст, подготовка к выводу - вью

я от контекста/сервиса получаю комменты, их общее количество и кол-во на странице

ну формально-то контроллер у нас подготавливает переменные для отображения во вьюсе

например

это не гуд?

тут не просто комменты человек считает, а pending, populate, какие-то еще. Фильтровать и считать это эликсиром - долго и не эффектиивно

+

я от контекста/сервиса получаю комменты, их общее количество и кол-во на странице

например как?

в контексте функция возвращает тульпу

3 функции

хз

Если ты в контексте 3 раза в базу сходил

ну блин

Может и норм вернуть тупл из трёх переменных

В чем вообще соль этих контекстов, в них надо реализовывать предметную область/бизнес-логику; считать кол-во тех или иных комментариев - как раз оно и есть

а как иначе?

Ну если ты один раз в базу сходил

1 раз получить комментарии

1 раз количество всех

ну не эликсиром же их считать

Почему бы и не посчитать

ну если это будет быстрее - то да :)

По листу о(н)

но если есть пагинация

А комментариев максимум там 1000

то никак по другому количество всех ты не узнаешь

я просто еще далек от этого

когда ЯП может посчитать быстрее БД :)

ну не эликсиром же их считать

ну давай, напиши мне, как получить комментарии с оффсетом и этим же запросом вернуть их количество на странице

да не это количество moi_nik считает

та он ваще хз что считает

ну как бы 2 разные вещи - вернуть кол-во элементов в листе

и сгруппировать их по какому-то условию и считать кол-во

ну давай, напиши мне, как получить комментарии с оффсетом и этим же запросом вернуть их количество на странице

разумеется, в экто

В чем вообще соль этих контекстов, в них надо реализовывать предметную область/бизнес-логику; считать кол-во тех или иных комментариев - как раз оно и есть

+

разумеется, в экто

подзапросы нельзя делать в экто?

о понеслась

можно, давайте нахуевертим трёхэтажный неподдерживаемый sql

неукоснительное соблюдение подобных правил - глупо. всё зависит от контекста

В чем вообще соль этих контекстов, в них надо реализовывать предметную область/бизнес-логику; считать кол-во тех или иных комментариев - как раз оно и есть

попытки запихнуть всё в контекст ничем не лучше любого другого подхода

во главу угла надо ставить читаемость и поддерживаемость кода. если Enum.count() во вью решит задачу - это куда лучше подзапроса в контексте

на CircleCI, например, нельзя превышать 4G, кто-нибудь знает, это можно как-то указать для test-env? иначе CI просто убьёт процесс и все :)

я вот сейчас как раз разгребаю дерьмишко за любителями всего этого

можно сделать что угодно, если это решает задачу

def all(user, :current_user) do from( n in __MODULE__, join: tu in User, on: tu.id == n.target_user_id, left_join: tp in Post, on: tp.id == n.target_post_id, left_join: su in User, on: su.id == n.source_user_id, left_join: sp in Post, on: sp.id == n.source_post_id, where: n.target_user_id == ^user.id, where: is_nil(tu.deleted_at) and is_nil(tp.deleted_at) and is_nil(su.deleted_at) and is_nil(sp.deleted_at), group_by: [ n.action, n.target_user_id, n.target_post_id, fragment("round(extract(epoch from ?) / ?)", n.happened_at, @interval) ], order_by: [desc: fragment("happened_at")], select: %{ action: n.action, happened_at: fragment("MAX(happened_at) as happened_at"), target_posts:

Если бы вопрос был бы просто вернуть кол-во, то Enum.count был бы решением, но это не тот случай

круто жи? бизнес-логика в контексте, о, и подзапросы есть

как то ужасно

полностью постить не стал - там несколько страниц

можно же ещё добавить

и ещё

и ещё

а если сделать виртуальный филд, то ваще всё с базы в одном запросе собрать

охуенно жи?

ты придумал GraphQL

ой, оно выполняется 1300 мс на нескольких тысячах, но ничё? железо же помощнее можно купиь

:D

я не придумал, я разбираю этот звездолёт

group_by: [ n.action, n.source_user_id, fragment("round(extract(epoch from ?) / ?)", n.happened_at, @interval) ],

вот это мне нравится особо

а че не так?

round(extract(epoch from ?) / ?) - это конечно можно лучше написать скорее всего

а лучше удалить

на самом деле там запрос в целом не очень

но это не значит что разбиение на контексты - зло

но в целом, если интервал любой может быть любой - то норм

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

и будет норм, возможно

но это не значит что разбиение на контексты - зло

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

разумный подход нужен ко всему

но в целом, если интервал любой может быть любой - то норм

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

это да

люблю такие запросы писать в миграциях данных :))) особенно cte и рекурсии

миграции зачастую одноразовый код же

особенно миграции данных

Ммм, миграция данных завернутая в транзакцию

Каеф

ага, сочные запросики мммм

Если что не так постгрес всегда откатит пара гигов))

Ну или десятков

Глупый вопрос, наверное. Но все же. nif-ы же могут паралельно работать?

Глупый вопрос, наверное. Но все же. nif-ы же могут паралельно работать?

в количестве scheduler threads или dirty schedulers в зависимости от версии beam, еяпп

вроде не запрещено поднимать свой тред пул из инициализации нифа, но это не точно