AS
Ну почему Monad[F] более достойная имплисита, чем MyRepo[F] ?
Как-то хочется разделить всякие "системные" вещи от компонентов приложения. Не знаю, может это стереотипы.
Size: a a a
2020 March 15
Oℕ
А зачем вам вообще модуль, параметризованный Db и F одновременно?
AS
А зачем вам вообще модуль, параметризованный Db и F одновременно?
Чтобы переход от DB к F был явным, запускается транзакция. А как иначе?
AS
Плюс не даем делать долгие транзакции, т.к. нельзя вставить F в цепочку DB вызовов.
Oℕ
Чтобы переход от DB к F был явным, запускается транзакция. А как иначе?
Сделать MyRepo[F], реализовать для DBIO, потом через трансформацию превратить его UserRepo[FinalType]
V
Сделать MyRepo[F], реализовать для DBIO, потом через трансформацию превратить его UserRepo[FinalType]
Так не получится объединить несколько операций в одну транзакцию
Oℕ
Так не получится объединить несколько операций в одну транзакцию
Получится
V
Как, если у тебя каждый раз будет коммит
Oℕ
Если где-то нужно выполнять несколько операций в одной транзации, нужно их вытащить в отдельный модуль AnotherRepo[F]
Таким образом транзакционность не будет протекать
Таким образом транзакционность не будет протекать
V
Звучит как план
Oℕ
Что интересно, если сейчас вы сделаете даже какой-то
макросы из cats tagless и тофу смогут имплементировать вас FunctorK, ApplyK, Embed, RepresentableK и т.д, если соотв. инстансы есть для вложенных модулей
trait MyRepoPackage[F[_]]{
implicit def users: UserRepo[F]
implicit def operations: UserOperations[F]
...
}
макросы из cats tagless и тофу смогут имплементировать вас FunctorK, ApplyK, Embed, RepresentableK и т.д, если соотв. инстансы есть для вложенных модулей
AS
Если где-то нужно выполнять несколько операций в одной транзации, нужно их вытащить в отдельный модуль AnotherRepo[F]
Таким образом транзакционность не будет протекать
Таким образом транзакционность не будет протекать
Как-то не очень. Мне нравится комбинировать вызовы Repo именно в сервисе, плюс один метод Repo - это один SQL запрос.
Oℕ
Как-то не очень. Мне нравится комбинировать вызовы Repo именно в сервисе, плюс один метод Repo - это один SQL запрос.
Ну видите, это приводит к тому, что
A) Типы, которые обычно являются проводниками по структуре вашего приложения и теперь не смогут помочь, если часть состояния вы решите вынести из SQL, обложить кешами и т.п. Вы явно семантически привязали себя к транзакционности
Б) Настолько явно, что без информации в типе считаете количество SQL по количеству композированных методов. Т.е. уже проложили себе дорожку на тёмную сторону ссылочной непрозрачности.
A) Типы, которые обычно являются проводниками по структуре вашего приложения и теперь не смогут помочь, если часть состояния вы решите вынести из SQL, обложить кешами и т.п. Вы явно семантически привязали себя к транзакционности
Б) Настолько явно, что без информации в типе считаете количество SQL по количеству композированных методов. Т.е. уже проложили себе дорожку на тёмную сторону ссылочной непрозрачности.
V
Ну видите, это приводит к тому, что
A) Типы, которые обычно являются проводниками по структуре вашего приложения и теперь не смогут помочь, если часть состояния вы решите вынести из SQL, обложить кешами и т.п. Вы явно семантически привязали себя к транзакционности
Б) Настолько явно, что без информации в типе считаете количество SQL по количеству композированных методов. Т.е. уже проложили себе дорожку на тёмную сторону ссылочной непрозрачности.
A) Типы, которые обычно являются проводниками по структуре вашего приложения и теперь не смогут помочь, если часть состояния вы решите вынести из SQL, обложить кешами и т.п. Вы явно семантически привязали себя к транзакционности
Б) Настолько явно, что без информации в типе считаете количество SQL по количеству композированных методов. Т.е. уже проложили себе дорожку на тёмную сторону ссылочной непрозрачности.
А что плохого в транзакционности
V
Если она есть в приложение, то лучше знать об этом
V
Чем пытаться спрятать - нет?
AS
Ну видите, это приводит к тому, что
A) Типы, которые обычно являются проводниками по структуре вашего приложения и теперь не смогут помочь, если часть состояния вы решите вынести из SQL, обложить кешами и т.п. Вы явно семантически привязали себя к транзакционности
Б) Настолько явно, что без информации в типе считаете количество SQL по количеству композированных методов. Т.е. уже проложили себе дорожку на тёмную сторону ссылочной непрозрачности.
A) Типы, которые обычно являются проводниками по структуре вашего приложения и теперь не смогут помочь, если часть состояния вы решите вынести из SQL, обложить кешами и т.п. Вы явно семантически привязали себя к транзакционности
Б) Настолько явно, что без информации в типе считаете количество SQL по количеству композированных методов. Т.е. уже проложили себе дорожку на тёмную сторону ссылочной непрозрачности.
Частично согласен. Но А) решается по мере возникновения проблем, 99% случаев не потребуют кэша все равно. Б) это чисто соглашение, ничего не считаем
Oℕ
Чем пытаться спрятать - нет?
Нет. Любая абстракция - это и есть попытка спрятать нерелеватную информацию.
Когда у вас появляется необходимость переписать приложение, типы должны сообщить: "вот всему этому коду всё равно, откуда и как вы складываете эти три переданных параметра. Внутри SQL транзакции они, или порождают событие в кафке или улетают в скрипт на аэроспайке."
Вместо этого вы получаете информацию "всё приложение писалось с учётом транзакционности всего состояния. Если какая-то часть отойдёт от общего плана, предсказать, что пойдёт не так - почти невозможно, лучше напишите всё заново"
Когда у вас появляется необходимость переписать приложение, типы должны сообщить: "вот всему этому коду всё равно, откуда и как вы складываете эти три переданных параметра. Внутри SQL транзакции они, или порождают событие в кафке или улетают в скрипт на аэроспайке."
Вместо этого вы получаете информацию "всё приложение писалось с учётом транзакционности всего состояния. Если какая-то часть отойдёт от общего плана, предсказать, что пойдёт не так - почти невозможно, лучше напишите всё заново"
Oℕ
Частично согласен. Но А) решается по мере возникновения проблем, 99% случаев не потребуют кэша все равно. Б) это чисто соглашение, ничего не считаем
Ну я к тому, что можно получить заранее почти бесплатно структуру, которая поможет решить часть поступивших проблем.
Просто нужно избавиться от иллюзии комфорта при работе с базой в полуявном виде внутри вашей бизнес логики
Просто нужно избавиться от иллюзии комфорта при работе с базой в полуявном виде внутри вашей бизнес логики
V
Нет. Любая абстракция - это и есть попытка спрятать нерелеватную информацию.
Когда у вас появляется необходимость переписать приложение, типы должны сообщить: "вот всему этому коду всё равно, откуда и как вы складываете эти три переданных параметра. Внутри SQL транзакции они, или порождают событие в кафке или улетают в скрипт на аэроспайке."
Вместо этого вы получаете информацию "всё приложение писалось с учётом транзакционности всего состояния. Если какая-то часть отойдёт от общего плана, предсказать, что пойдёт не так - почти невозможно, лучше напишите всё заново"
Когда у вас появляется необходимость переписать приложение, типы должны сообщить: "вот всему этому коду всё равно, откуда и как вы складываете эти три переданных параметра. Внутри SQL транзакции они, или порождают событие в кафке или улетают в скрипт на аэроспайке."
Вместо этого вы получаете информацию "всё приложение писалось с учётом транзакционности всего состояния. Если какая-то часть отойдёт от общего плана, предсказать, что пойдёт не так - почти невозможно, лучше напишите всё заново"
Приложение с eventual consistency так или иначе отличается от транзакционного