БД тут — это не SQL база данных, а набор файлов, в котором прописано сопоставление между регулярками, которые применяются к user agent'ам, и названиями, версиями браузеров и устройств

Вот эта БД, по сути (её текущее состояние)

Короче, как я сумел понять по обсуждению, ua_inspector - это мультикомбайн, который и user-agent парсит, и в базу сам ходит, и ещё какие-то задачи делает. Зачем так сделано - непонятно, но если так - это кандидат на выпил номер один.

А вот это норм вариант

Это просто ты увидел знакомое слово (БД), сам себе что-то придумал, сам сделал вывод и поспешил высказать своё экспертное мнение. А ведь можно было просто пойти на страничку проекта (я даже не говорю уже про то, чтобы прочитать документацию). В общем, оставайтся на линии.

Можно было и сырцы посмотреть. Специально для умников написал "по обсуждению тут", ибо проскакивали миграции и тогдалие.

Специально для умников, "по обсуждению тут" прямым текстом ранее было написано, что БД ua_inspector — это не SQL БД, а набор файлов, да и по контексту можно было догадаться.

Кокое "заранее", мы с тобой одновременно текст набирали.

Вот, например

https://t.me/proelixir/141938
https://t.me/proelixir/141939
https://t.me/proelixir/141944

Да (ц)

Что могу сказать по задаче "регулярки хранятся в priv, может их положить в БД миграцией?"
Во-первых, простейший способ - положить в version control и периодически апдейтить.
Во-вторых, добавлять данные в БД через миграции в целом можно. Это сложнее, но иногда они требуются для логической консистентности приложения, а иногда позволяют решить проблемы, которые сам себе создал.
Основная разница этих способов - в итеративном накатывании миграций БД. Код в репозитории отражает только текущее логическое состояние, а данные в базе и код миграций несут на себе печать истории. Может так получиться, что до мержа PR в базе лежали валидные инварианты, а после мержа - уже не валидные.
Эта проблема бывает заметна на долгоживущих проектах - у девелоперов, которые работают с проектами давно и периодически накатывают новые миграции, окружение настроено. Но новый разраб, разворачивая проект с нуля, и накатывая все миграции, обнаруживает, что какая-нибудь старая миграция валится, и нужно пойти руками в базу что-то подправить, чтобы миграции пошли дальше. Причина в том, что эта старая миграция у всех разрабов и на проде выполнялась с расчётом на _тогдашнее_ состояние фикстур и данных в БД. А сейчас фикстуры уже уехали. Выход? При написании миграций не полагаться на состояние кода, фикстур, yml-бд и вообще всего что находится вне бд.
Резюмируя: оптимальный вариант - положить yml-файлы в version control и быть аккуратнее с миграциями.

Удваиваю, храню базу и парсер ua в гите в отдельном проекте. Если база обновляется, то у основного проекта просто обновляется зависимость

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

default.po
##Do not add, change, or remove `msgid`s manually here as
## they're tied to the ones in the corresponding POT file

Подскажите аналог dry-transaction для эликсира. Ну или монады, которыми можно пользоваться

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

Repo.transaction(fn ->
  with(
    :ok <- step1(),
    :ok <- step2()
  ) do
    :ok
  else
    ...
  end
end)

Repo.transaction(fn ->
  with(
    :ok <- step1(),
    :ok <- step2()
  ) do
    :ok
  else
    ...
  end
end)

thx

Спасибо. Но действительно - того, о чем выше написали мне хватит пока что. with - do - else - end
Но оперейшены я точно где-нить потом применю

Это разве не про ddd? В этой либе вроде нет транзакций. @madeinussr

возможно, я пока в ней не разбирался