Прошло уже очень много времени с момента как я писал про свои эксперименты с Erlang ORM.
И что я могу сказать?
Первое и самое, вероятно, печальное, подход оказался не жизнеспособным, Второе – несмотря на недостатки ORM ее использование помогло набраться опыта работы с postgresql из Erlang и получить представление о том как все действительно должно работать.
Где я допустил ошибки:
– Нельзя мешать в одной модели описание того как данные хранятся в базе и как будут отдаваться клиенту
– Не стоило мешать генерацию sql и непосредственную работу с БД в одном проекте
– Подход ActiveRecord – не самая лучшая идея для Erlang
– Слишком много parse_transform-a
За эти 2 года я очень часто сталкивался с генерацией sql в чужих проектах на Erlang и, к сожалению, единого, общепризнанного, да что там, хотя бы просто удобного решения нигде не встречал. Везде лишь ад из case блоков, сверток и iolist-ов. Что еще печальнее, коллеги все чаще стали поглядывать в сторону Elixir с его ecto. А уж совсем не хочется изучать, а тем более использовать в продакшене еще один язык.
Так на свет появился стек для работы с postgresql и моделями данных:
– epgpool – простой пулл подключений к postgres. Очередной велосипед, если есть предложения чего-то получше – могу рассмотреть
– dbschema – автоматические миграции наше все. Библиотек позволяет исполнять sql и erl up/down инструкции. Что убирает кучу работы по ручной раскладке и позволяет автоматизировать тестирование
– emodel – библиотека для валидации входных данных. Та самая прослойка, которая должна отделять чистые, проверенные данные от мусора, который к нам прилетает. Отличается тем, что возвращает сразу все ошибки до которых может дотянуться.
– equery – генерация sql, вдохновленная подходом Ecto
– repo – одна из возможных реализаций CRUD библиотеки поверх equery и epgpool.