т.е. если я в одной форе несколько фри композирую то оно не в одной транзакции будет выполняться,

val updatedRequest = request .modify(_.requestStatus).setTo(status) .modify(_.processTime).setTo(env.currentTime)

Спасибо, но в quicklens ничего и писать не надо ) только там на макросах а не на композициях

Спасибо, но в quicklens ничего и писать не надо ) только там на макросах а не на композициях

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

Да все это верно и круто. Но когда я изучал функциональные линзы то смущало много чего руками надо делать и как то это было нечитаемо что-ли. В scalaz. Хочется на месте тяпляп и изменил поля кейскласса

50% моего применения монокля квикленс никак не осилил бы

Если бы скинул примеры киллерфич из этих 50% то было бы круто

Насколько сложно рефакторить? Вот создал стопицот линз - их надо руками потом исправить если поля переехали в агрегат например?

Если бы скинул примеры киллерфич из этих 50% то было бы круто

В копилку еще то, что в идее есть небольшая поддержка монокля (не помню какое покрытие), но обычный результат @Lenses - точно в автокомплите доступен)

@ezhulkov А в квикленс идея краснит на .each ?

тест на репликанта?

@ezhulkov А в квикленс идея краснит на .each ?

Вопрос знатокам doobie, у него на сайте написано You can use a for comprehension to compose any number of ConnectionIO programs, and then call .transact(xa) on the result. All of the composed programs will run in the same transaction. For this reason it’s useful for your APIs to expose values in ConnectionIO, so higher-level code can place transaction boundaries as needed. Это ок и понятно, но в таком случае higher-level code полностью завязан на ConnectionIO и уже не может работать в другой монаде, например в monix Task Получается что либо вся бизнес логика живет в ConnectionIO и я имею одну транзакцию либо на каждый запрос к репе надо делать трансформацию из ConnectionIO в Task и это уже куча транзакций

а, собственно в ответе так и делают

а пример можно того что вы хотите сделать?

типа чтобы прочитать изменить сохранить и все в одной транзакции?

на мои взгляд эт дичь

обьясни мне, зачем тебе одна транзакция?

обьясни мне, зачем тебе одна транзакция?

Бывают ситуации, где это надо, типо дохера сильные требования к консистентности

открой so

я бы просто добавил версионность и оптимистик апдейт

Чтобы так сделать, надо изначально закладывать эту возможность, а если например у людей особо нагрузки нет (типо пишут коробку для предприятий в 100 человек), нахрена им городить эти сложности, почему нельзя взять и запустить одну транзакцию на операцию?

По-моему спрашивать «зачем тебе одна транзакция» как-то странно

Есть разные требования и разные решения ?‍♂️