там сказали спасибо и тоже заткнули щель

так и в экто

в ja_resource ребята почему-то посчитали, что клиент вообще всегда валидный json им пришлет

одна лишняя скобка и пердак под всем апи взрывается

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

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

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

самое главное что дыры затыкаются и достаточно шустро

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

сам подход - говно

кстати, интересный момент с эликсиром

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

с вендой всё сложнее

Я всё-таки не могу понять, почему это называется заделыванием дыр

у них всё закрыто

плюс нет нормальной обратной связи

По-моему все логично сделано

Я правда ещё не смотрел как сделаны адаптеры

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

фактически их аппы не готовы к проду

чуть что, эликсир взрывает апп )

Объясните где с уидом затыкание дыр

Все же логично

Да и вообще с протоколом Ecto.Type все логично

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

и решают в какие-то разумные сроки

а тот же микрософт десятками лет не исправляет порой

я ещё раз посмотрел про cast

и понял что мы не там смотрели

с кастингом-то всё в порядке

у Александра претензия другого рода

https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/query/planner.ex#L567

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

сейчас проверю что происходит при роутинге

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

Так а что это за Planner?

А, блин

это когда запрос пытаемся выполнить, он все подготовительные действия в планнере делает

https://github.com/elixir-ecto/ecto/issues/1705#issuecomment-302339798

Те если сделать Query с невалидным уид, то будет запрос к базе

Но это логично

Вообще говоря

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

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

Так и есть в дзене феникса

Чейнджсет не привязан к бд

Им параметры тоже проверяют

ну это да и на ruby-way похоже и с erlang-way не сильно конфликтует

https://github.com/vic/params/blob/master/README.md

Всякие такие либы

Хотя идея с инвалидацией запроса по-моему очень крутая

Нафига трогать базу, если заранее понятно что в запросе хуита?

Надо Rfc пилить

https://github.com/elixir-ecto/ecto/pull/1704/commits/7958819536885d5ef83dfb278ba65a324a10faec

вот его тесты

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

А расскажите как принято тестировать различные message queue? Есть какой-нибудь бенчмарк, к которому можно привязаться и посмотреть реальную производительность?

у раббита есть графики в веб морде =)

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

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

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

и смотрим через веб морду какая пропускная способность

А что такое get?

А что такое get?

https://hexdocs.pm/ecto/Ecto.Repo.html#c:get/3

Все верно, я что-то протупил

Если я всё-таки понимаю правильно get под капотом генерирует from select where id =

Так вот надо это самое query поменять

ERROR: S client not available

На аналога changeset

Те чтоб там было поле valid

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

я сразу под свои задачи сделал воркеров и паблишеров и у меня по сей день работает =)

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

https://github.com/elixir-ecto/ecto/blob/v2.1.4/lib/ecto/query.ex#L5 Вот тут вот поменять

Добавить поле

И соответственно для query builder возможность инвалидировать

я сразу под свои задачи сделал воркеров и паблишеров и у меня по сей день работает =)

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

Коллеги, приглашаем вас на очередной московский Elixir митап 14 июня в Rambler & Co. В программе: ets, нейронные сети, философия. Регистрация открыта: http://elixir-lang.moscow/

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

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

также я сомневаюсь что не имея брокера очередей сейчас получиться хотя бы на 10К/секунду грузануть любой брокер очередей (реальной нагрузкой)

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

и зная о них заранее

да и вообще бенчмарки обычно связаны с манипулированием

http://nats.io/documentation/tutorials/nats-benchmarking/

1млн сообщений с пэйлоадом в 16 байт =)

я даже представить не могу задачу где надо что-то по 16 байт пересылать

у меня пэйлоады были в среднем 200 байт - 80 килобайт

чтобы у меня это заработало на натсе, мне бы пришлось править конфиг (там ограничение из коробки в 65 килобайт)

а с раббитом я ничего не настраивал в конфигах в одиночном режиме (настраивал когда кластер собирал)

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

сейчас меньше тысячи в секунду

и хватает

так что все эти бенчмарки от лукавого

https://content.pivotal.io/blog/rabbitmq-hits-one-million-messages-per-second-on-google-compute-engine

вот раббит разогнали до миллиона запросов в секунду

на 32 серверах

но я не нашёл подробностей (но судя по всему на реальных данных гоняли, потому что там пара сотен очередей, это немало)

какие пэйлоады были (это очень важно), какое железо и.т.п.

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

производительность у них различается на порядки

в рабите есть у задач метаданные