javap выдаёт только шапку класса и сигнатуры методов

Хм. Когда я последнийраз смотрел, он выдавал все.. JAD?

Это довольно типичный паттерн. Люди писали на Спринге свои бинчики, потом узнали про Акку и решили что акторы - это замена бинам :D

ну есть такие да знаю лично парочку

javap выдаёт только шапку класса и сигнатуры методов

Ты прав. Это у меня в alias пробит javap и jad.

http://jd.benow.ca

jad сработал, спасибо

/toxic

jad сработал? странно

последни раз он и на жаве треш выдавал

jd-gui более менее, fernflower получше

fernflower в идею встроен

его еще где-то на гибхабе можно найти и собрать отдельно

Вопрос знатокам 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 и это уже куча транзакций

как делаете вы? нужна 1 транзакция на кусок бизнес логики, но при этом хотелось бы работать в Monix Task например

Можно завязываться не на ConnectionIO, а на F[_]

у F[_] нет метода transact(xa) который и выполняет транзакцию

Зато у конвертора, который превращает F[_] в Task, он есть

чоза конвертор

не понимать

надо работать в одной монаде - желательно в одном из инстансов Async и делать так чтобы это была 1 транзакция

Сделали все что нужно с F[_], вызвали f2task(myResultOfTypeF)

f2Task это что-то типа def f2Task(q: ConnectionIO) = transactor.flatMap(xa => q.transact(xa))

q.transact(xa) в данном примере выдаст мне monix.Task потому что в этом эффекте я работаю

и как бы тут нужно натуральное преобразование тогда а не флатмап

val fResult: F[Int] = for { a <- doobieFunc1() b <- doobieFunc2() c <- doobieFunc3() } yield a + b + c val task1 = f2Task(fResult) val tResult: Task[Int] = for { d <- task1 e <- taskFunc() } yield d + e

Сначала сделали все что хотим в терминах F[_], потом сконвертили результат в таск и работаем с ним

это все понятно да а теперь представим что есть такой сценарий - идем в базу - обрабыватыем полученный объект в Task - записываем результат в базу

то есть в примере выше сразу после taskFunc идет еще один поход в базу

Тогда это не получится сделать в одной транзакции

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

хм это странное ограничение

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

Если так нужно все делать в одной транзакции, почему не сделать всю работу в функциях doobieFunc1(), doobieFunc2(), ..., doobieFuncN(), а потом просто сконвертить в таск?

никто не мешает в самом конце цепочки композиций сделать commit

потому что конвертация в таск - это граница транзакции

Что-то не видно комитов новых с 9 мая, кто-нибудь знает почему? https://github.com/scalameta/metals

потому что конвертация в таск - это граница транзакции

Сконвертить в конце, в не посреди выполнения работы

Сконвертить в конце, в не посреди выполнения работы

значит и остальная логика должна работать в ConnectionIO иначе просто не построишь композицию монад

Ну, пытаться вызвать методы, возвращающие Task внутри транзакции, это имхо как-то стремно

Как минимум

В транзакции должно выполняться что-то очень быстрое

А не таски, которые делают rest-запросы к внешней системе ?

Точно так же как вызывать очень тяжелые блокирующие операции внутри таска с пулом в 3 потока неправильно

да проще - cpu intensive операцию которую хочется запускать в отдельном пуле например

не обязательно REST

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

ладно спасибо, напишу пока в SO вопрос :)

Можно сделать свой TxManager, который используешь в тасках

Создаешь transactor val connection = dataSource.getConnection connection.setAutoCommit(false) Transactor[Task, Connection]( connection, c => Task.pure(c), KleisliInterpreter[Task].ConnectionInterpreter, Strategy.void )

В конце своей транзакции import cats.implicits._ import doobie.free.connection import doobie.free.connection._ trasactor.rawTrans.apply(connection.commit *> connection.close)

Полностью код скинут не могу

да интересно а что возвращает слой репы? ConnectionIO?

Task

то есть в репе смело делать .transact(xa) но потому что мы подсунули свой транзактор ничего не будет происходить?

ага

спасибо буду в эту сторону смотреть :)

И код легче становится Ты оперируешь своими объектами, clean architecture и все такое

да звучит круто

а потом забыл закомитить

Выглядит как хак, но если уж так решать проблему, то проще сделать val noTransactionsXa = Transactor.before.set(xa, FC.unit)

Но что потом? Тащить транзактор во все классы и коммитить руками? ? Звучит не очень

зачем везде тащить? есть 1 сервис http4s, в самом конце обработки закомитить

пока других вариантов открыть транзакцию на всю обработку и закомитить в самом конце я не нашел ) может еще что-то на stack overflow напишут посмотрим

Полностью вся обработка запроса внутри транзакции? ? Жестоко

Старый добрый паттерн для веба )

https://twitter.com/jdegoes/status/998900201535389701?s=19

ERROR: S client not available

Жирно

Это да, в кложе не так, сильно лучше в этом плане

так транзактор же превращает ConnectionIO[A] в Monad[A]

короче я пропустил всё =)

так транзактор же превращает ConnectionIO[A] в Monad[A]

Он не только превращает, он и исполняет ее. В итоге каждый поход в БД превращается в свою независимую транзакцию а хочется все в одной

Где сейчас самый удобный моноколь\линзы\etc ? есть pure scala проект, думаю что вкатывать

В монокле

Я quicklens использую. Не совсем линзы но смысл тот же и очень удобно

How do I do several things in the same transaction? 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.

Я с этого и начал вопрос

В монокле

Thx

Transact ничего не исполняет, а делает монадку

Он не только превращает, он и исполняет ее. В итоге каждый поход в БД превращается в свою независимую транзакцию а хочется все в одной

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

?

Transact ничего не исполняет, а делает монадку

Которая исполнятся когда запускаешь эффект, например runUnsafe

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

Если то что ты композируешь это ConnectionIO и результат тоже ConnectionIO а потом делать transact то да - одна транзакция

Я quicklens использую. Не совсем линзы но смысл тот же и очень удобно

А оно умеет если внутренности ещё в option все попрятаны?

А оно умеет если внутренности ещё в option все попрятаны?

наверняка, но зачем

если есть монокль

Option это список так что умеет

Option это список так что умеет

опшон - это не список

Я грубо. Iterable. А у quicklens есть each который позволяет пробежаться по коллекции

Option это список так что умеет

Но справедливости ради стоит упомянуть, что в кметтовских lens тоже нет Optional и в его рли юзают Traversal

если есть монокль

Монокль видимо умеет

Монокль видимо умеет

Монокль умеет изменить сразу много полей?

Монокль видимо умеет

да ^|-? some

Монокль умеет изменить сразу много полей?

сразу много полей разных типов?

или пробежаться по коллекции?

Взять и изменить половину полей кейскласса

Взять и изменить половину полей кейскласса

пример плиз

я полашаю, что для монокля это просто композиция функций

Взять и изменить половину полей кейскласса

Сделать композицию из линз?