внешними системами?
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
ну также при инициализации в application можно указать {YourLibrary, [YouApp.Repo]}, если я правильно поняла вопрос
если это довольно абстрактный кусок, то вынести его в behaviour, а реализацию можно подставлять в тот же модуль через compile_env + defdeligate. Довольно часто используется.
> реализацию можно подставлять в тот же модуль через compile_env + defdeligate. а можно где-то пример увидеть?
Не понял ситуации. Нужно сделать MyApp.Repo параметром?
И что такое "подвешанные замыкания"? Погуглил — не нашёл
@LamaLove вот это вчерашнее
А вот для зависимости, которая использует репо проекта, который её использует, я бы сначала ответил на два вопроса 1) Зачем использовать Repo? Типа Repo это же просто набор функций, исполняющих запросы. Разве не достаточно предоставить только запросы? 2) А почему бы не предоставлять свой Repo, чтобы проект-хост использовал его? Я с таким подходом прямо сейчас работаю и в нём ничего страшного нет ...
1 - вот это зависит. да, можно наружу отдать Multi, но в такой ситуации нет возможности оттранслировать ошибки.
Обсуждают сегодня