AD
или в конфиге
Size: a a a
2020 October 22
AB
или в конфиге
да, конфиг это в принципе самый простой вариант.
AB
отдельный интересный вопрос, кстати, миграции. в экто они намертво прибиты к repo(точнее, приложению, но именно через repo).
AB
вообще, я так смотрю на это всё, и кажется мне, что с появления эликсира не решили по большому счету ни одной по-настоящему актуальной для beam проблемы.
AB
(что самое смешное, в кложе в это же самое время - решали, как минимум, вопрос инициализации, результатом чего стал integrant, например)
ŹR
вообще, я так смотрю на это всё, и кажется мне, что с появления эликсира не решили по большому счету ни одной по-настоящему актуальной для beam проблемы.
Довольно странное заявление. Есть язык а есть код на нем - это разные вещи
AB
язык это не код, это комьюнити и майндсет
AB
ну то есть, код, конечно, есть тоже - но это производная.
ŹR
Коммунити эликсира писало рельсу все эти годы
AB
надо подумать мысль, что же можно получить из возможности класть в persistent_term замыкания целиком.
ŹR
Цель видимо выполнена
ŹR
Теперь надо двигаться дальше, хз куда правда
VS
вот кстати, как бы вы делали реюзабельный контекст, работающий с внешними системами?
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
если это довольно абстрактный кусок,
то вынести его в behaviour,
а реализацию можно подставлять в тот же модуль
через compile_env + defdeligate.
Довольно часто используется.
то вынести его в behaviour,
а реализацию можно подставлять в тот же модуль
через compile_env + defdeligate.
Довольно часто используется.
AB
если это довольно абстрактный кусок,
то вынести его в behaviour,
а реализацию можно подставлять в тот же модуль
через compile_env + defdeligate.
Довольно часто используется.
то вынести его в behaviour,
а реализацию можно подставлять в тот же модуль
через compile_env + defdeligate.
Довольно часто используется.
> реализацию можно подставлять в тот же модуль через compile_env + defdeligate.
а можно где-то пример увидеть?
а можно где-то пример увидеть?
LL
вот кстати, как бы вы делали реюзабельный контекст, работающий с внешними системами?
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
Не понял ситуации. Нужно сделать
MyApp.Repo параметром?LL
вот кстати, как бы вы делали реюзабельный контекст, работающий с внешними системами?
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
типа, есть какой-то довольно абстрактный кусок кода, работающий с базой - у него там внутри сколько-то табличек, на них есть вполне независимый комплект миграций, он предоставляет какой-то там интерфейс.
сейчас в нем явно прописан используемый экземпляр Ecto.Repo. можно repo вынести в параметр каждой функции в контексте, но это определенно не масштабируется - если ему потребуется очередь, станет 2 параметра.
можно вынести в отдельный параметр не просто repo, а целую пачку сервисов окружения, но тем не менее, это параметр, который нужно везде таскать.
в кложе это решается подвешенными замыканиями, или reified протоколами, или еще как-нибудь, короче провязывается на фазе инициализации(см. integrant/component). в beam для этого ничего готового нет, а clojure way сделать малореалистично из-за "модулеориентированности" всего инфраструктурного кода.
И что такое "подвешанные замыкания"? Погуглил — не нашёл
LL
отдельный интересный вопрос, кстати, миграции. в экто они намертво прибиты к repo(точнее, приложению, но именно через repo).
> они намертво прибиты к repo
А как ещё может быть?
А как ещё может быть?
Repo это паттерн, который заключается в том, что есть всего лишь одна сущность, которая исполняет запросы к одной базеLL
две базы — два
RepoLL
Какой-нибудь
Active Record вообще антифункциональный и в BEAM очень плохо смотритсяAB
> они намертво прибиты к repo
А как ещё может быть?
А как ещё может быть?
Repo это паттерн, который заключается в том, что есть всего лишь одна сущность, которая исполняет запросы к одной базея нашел, что в Ecto.Migrator есть run/4, куда можно руками передать путь до миграций в другом приложении, так что, не всё так плохо.
но то, что Repo как-то связывается с приложением, где он задекларирован, для меня дурно пахнет.
но то, что Repo как-то связывается с приложением, где он задекларирован, для меня дурно пахнет.