Size: a a a

2021 April 06

Н

Николай in pro.elixir
А раст не постигла участь С++ - лепить на языке все подряд?
источник

LL

Lama Lover in pro.elixir
Чат, а какие есть правильные способы подключать зависимость и давать ей пользоваться Repo из основного проекта?
Можно указывать в репо конфигурации к зависимости, можно делать так, чтобы у зависимости функции возвращалаи Ecto.Queryable или Ecto.Multi, можно передавать Repo первым аргументом в функции с запросом и всё такое
А какой способ лучший?
источник

Н

Николай in pro.elixir
Мне кажется более понятно было бы передавать Repo параметром через конфиг либы или при инициализации в ту либу.
источник

Н

Николай in pro.elixir
Т.е. чтобы либа не лезла сама и не пыталась хитро вытащить как-нибудь Repo, если я правильно тебя понял. Лучше explicit over implicit.
источник

LL

Lama Lover in pro.elixir
Не, такой вариант тут даже не рассматривается
источник

Н

Николай in pro.elixir
По каким соображениям? :D
источник

ŹR

Źmićer Rubinštejn in pro.elixir
config :super_liba,
   repo: MyHernya.Repo
источник

Н

Николай in pro.elixir
this :D
источник

ŹR

Źmićer Rubinštejn in pro.elixir
источник

Н

Николай in pro.elixir
источник

LL

Lama Lover in pro.elixir
Проблема с тем, что если зависимость сама использует Repo, мы не контроллируем запросы и может получиться что мы слишком часто дёргаем базу
Аля, достать пользователя, достать его посты, достать их комменты. Это будет три запроса. Если нужна атомарность, то это будет ещё и в транзакции

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

Один из вариантов такого — чтобы из приложения торчали Ecto.Queryable, Ecto.Changesеt или Ecto.Multi, которые можно было бы компонировать как-нибудь в один запрос. Но тут проблема в том, что не посмотрев в код зависимости не получится понять нужен тут, например, Repo.one или Repo.all
источник

DF

Denis Fakhrtdinov in pro.elixir
Мне кажется вообще странным передавать базу в депенденс.
источник

LL

Lama Lover in pro.elixir
Согласен, но когда приложение достаточно большой монолит, нужно как-то следить за пересечениями контекстов
Лучше всего просто разделять на зависимости и явно указывать кто от кого зависит
Иначе, придётся использовать какой-нибудь Boundary или clean_mixer от госпади-прости фанбокса
источник

M

Mexx in pro.elixir
Ecto вопрос
источник

M

Mexx in pro.elixir
Есть changeset который апдейтит какие то поля в структуре, именно на этот апдейт есть required_fields валидация. Если передавать запрос типа: changeset( %User{}, params) и  параметры отсутствуют, то экто выдаёт ошибку валидации. Но, если передавать: changeset(user_struct_current_from_db, params) то валидация не проходит, так как required_fields уже в user_struct_current_db
источник

M

Mexx in pro.elixir
Код древний, падает тест на валидацию - из-за каких то изменений в других местах: возможно так было задуманно в старых версиях ecto, возможно баг или в чем то другом трабла
источник

M

Mexx in pro.elixir
Собственно вопрос в том, а должна ли работать валидация, если данные уже есть в передаваемом struct?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Валидируются данные а не «текущие» данные. Это валидация на уровне модели.
источник

AD

Anastasiya Dyachenko in pro.elixir
покажи ошибку
источник

M

Mexx in pro.elixir
Ошибки нет, тест ожидает есто error, а данные апдейтаются (тот параметр который отсутствует, не апдейтится)
источник