И в логе не можешь написать «для такого юзера на ноль не делится»

можно положить в мету логгера id пользователя между матчами

@nwalker И так тоже.

не очень красиво, но сработает

Или просто сделать два кейса

Причём каждый - в своей функции

Короче говоря, with - это как unwrap в расте

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

Не уверен что так можно

Но было бы круто

def request(id) do case User.get(id) do {:ok, user} -> case do_action(user) do {:ok, true} -> {:ok, true} {:error, error} -> {:error, {user, error}} end {:error, error} -> {:error, error} end end def request(id) do with {:ok, user} <- User.get(id), {:ok, true} <- do_action(user) do {:ok, true} else {:error, {user, error}} -> ... end end

Мне кажется сделать возвращение ошибки как {:error, error, user} или {:error, {error, user}} намного менее накладно, чем with трансформировать в case портянку.

В особенности, когда этот with состоит из 3 и более элементов.

Тогда это не 2 case-а, а 3+ case-ов вместо одного with-а. Признаюсь честно, я этого точно не смогу понять.

у меня with из 10-20 подряд) и ничо. щастлив))

У меня вот более интересный кейс с организацией кода. Вот есть модуль, в нем все функции кроме одной сами создают транзакцию. Одна должна вызываться уже в транзакции, потому что там там транзакция такая интересная снаружи.

По всем остальным критериям все функции однородны

И глаз режет, и придумать ничего не выходит

Я такие вещи обычно с макросами решаю.

Проверить не в транзакции ли мы и если нет - инициировать?

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

Пусть так остаётся с комментарием

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

И часть утилитарного кода на него перенести

Я думал проблема несколько в другом (в том, что трансакция везде повторяется), здесь тогда нужно смотреть..

То, что везде нужна транзакция для меня выглядит довольно естественным. Для тех кейсов, где она нужна, в вызывающем ее открывать не имеет смысла никакого, не его это дело.

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

и в некоторых местах я докатился до advisory locks =(

Или просто сделать два кейса

есть пара вариантов решения с with 1. самый красивый по-моему def find(id) do case Repo.get(Model, id) do %Model{} = model -> {:ok, model} nil -> {:error, :model_not_found} — тут можно райзить или номер передать если нужно end end … with {:ok, model} <- find(id) 2. with %Model{} = model <- Repo.get(Model, id) || {:error, :model_not_found}

1 мне больше нравится лично. with чистенький получается. с фолбэк контроллером можно else не делать

@apelsinka223 Он имел ввиду, что ошибка происходит где-то дальше. with {:ok, model} <- find(id), {:ok, ...} <- do_something

И если do_something возвращает ошибку, то для какого пользователя.

Из else нельзя получить доступ к model.

В коде Kazoo третьей версии ЕМНИП был code style, который в частности говорил о запрете на вложенные case. Подобные "лесенки" читаются сложнее, и потому обязательно должны быть распилены и раскиданы по функциям. Но там Erlang.

ИМХО в эликсире вложенные кейсы смотрятся прямо скажем не очень

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

@apelsinka223 Я так и предложил.

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

Ну вот я и говорю - пилим как в эрланге без with

Теоретически можно отркфакторить мой код с with

@Virviil Получится меньше кода и читабельнее код и ошибки самодостаточные.

Вероятно.

посоны

как книжка? https://www.labirint.ru/books/577008/

коли уж на то пошло

http://elixirstatus.com/p/nXym-asyncwith-v030-released-the-asynchronous-version-of-elixirs-with-

как книжка? https://www.labirint.ru/books/577008/

судя по цене книга отличная

судя по цене книга отличная

ага, и весит больше чем полкило

ага, и весит больше чем полкило

похоже там гранит науки

Или крупные буквы и поля по пять сантиметров.

в общем, если кто читал, фидбэк был бы кстати

Можно в группе ерлангистов кинуть запрос

Можно в группе ерлангистов кинуть запрос

есть линк на группу?

есть линк на группу?

https://t.me/erlangrus

спасибо

Random question: Кто-нибудь на Gigalixir пробовал проекты с сокетами деплоить? Ловлю 403 ошибку, документация на эту тему хромает. UPD: Вопрос снят.

могу наврать, но там nginx надо ещё конфигурить

ну или любой другой фронтенд сервер

gigalixir ближе к heroku в этом плане, не сильно много дают поконфигурировать, хотя консоль есть Не копал ещё глубоко

Нашёл эрический косяк в экто: Если ТРИГГЕРОМ в ИНСЕРТЕ задать какое-нибудь поле, то оно не задаётся в результирующей структуре после Repo.insert

Т.е. > Repo.insert(%User{}) {:ok, %User{id: 1, name: nil} > Repo.get_by(User, 1) %User{id: 1, name: "Вася"}

Если имя задаётся триггером

Я даже не знаю, в какое спортлото писать по этому поводу

добавь параметр returning: true

в ecto 2.2 добавили параметр, insert возвращает не делая запроса, т.е. только указанные поля в changeset, и id не настоящий

??

Нашёл эрический косяк в экто: Если ТРИГГЕРОМ в ИНСЕРТЕ задать какое-нибудь поле, то оно не задаётся в результирующей структуре после Repo.insert

с триггерами в экто все потрачено. Вот в предпоследнем комменте есть описание, как это работает insert https://github.com/elixir-ecto/ecto/issues/1966

Хрень собачья

Ну хоть починить как то можно

Repo.insert не читает после записи же. Можно read_after_write указать, тогда все по идее должно быть норм

Я никогда на это внимания не обращал, а тут типо все знают

Прост интересно откуда

Потому что инсерт в sql не возвращает добавленные данные сам по себе, для этого надо делать отдельный селект. Если бы в экто этот селект принудительно делали неявно, был бы ппц.

Потому что инсерт в sql не возвращает добавленные данные сам по себе, для этого надо делать отдельный селект. Если бы в экто этот селект принудительно делали неявно, был бы ппц.

Зачем он тогда возвращает структуру?

0 логика

Очевидно, потому триггеры нечасто используются и структура, которую вернёт селект будет такой же => этот селект будет лишним только оверхедом. А если всё-таки надо, то есть та опция, о которой была речь выше.

вообще конечно, это стоило бы отметить в документашке по insert

Вообще конечно это есть в доках, но вопрос «зачем возвращают структуру» остаётся открытым

Потому что в продукте, который позиционирует себя настолько explicit - это просто дыра

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

Если ты выдаёшь объект после инсерта, то он должен быть консистентным

Это было б “не френдли"

Самое Френдли - это AR

Где вообще нету чейнджсетов

йеп, и поэтому такое большое комьюнити)

Можно было бы сказать, что они делают так под easy controllers

Но жато используется не только в фениксе

Так что ребята проебались как по мне

Ну вернее я проебался, потому что пропустил это в доке, потому что думал что если возвращается объект - то он соответствует бд )

так если ты чего-то засунул в changeset кинул это в БД и оттуда пришло все ok, то очевидно, что в БД тоже самое что и в changeset, так почему бы этот changeset не преобразовать в schema для удобства

тем более что это работает, и весьма неплохо

0 логика

в мире много удивительного https://github.com/benoitc/hackney/issues/371

так если ты чего-то засунул в changeset кинул это в БД и оттуда пришло все ok, то очевидно, что в БД тоже самое что и в changeset, так почему бы этот changeset не преобразовать в schema для удобства

Ну потому что это преобразование должно производится отдельной функцией explicitly

А иначе все превращается в Руби