Y
не, прост я люблю дуби
завернули resultset в kleisli смотрите какая хорошая либа
Size: a a a
2020 April 08
AT
завернули resultset в kleisli смотрите какая хорошая либа
Да
Oℕ
завернули resultset в kleisli смотрите какая хорошая либа
оч не люблю мат в основе в случаях, когда реплика не несёт вообще никакой информации, кроме персонального отношения собеседника к чему-то
Oℕ
ну во фримонадных обёртках над реляционными дровами идея не результсет завернуть в клейсли, а ограничить набор действий, которые можно делать внутри транзакции, чтобы нельзя было асинхронное ожидание воткнуть
Б
ну во фримонадных обёртках над реляционными дровами идея не результсет завернуть в клейсли, а ограничить набор действий, которые можно делать внутри транзакции, чтобы нельзя было асинхронное ожидание воткнуть
но в случае с ConnectionIO это можно сделать
Б
потому что для него есть асинк
I
В Lagom под капотом есть реализация.
Интересно, искали там но не нашли, написали сами на Lagom, может тыкнешь пальцем где она там? ;-)
ЮБ
но в случае с ConnectionIO это можно сделать
Там нет concurrent зато
Б
Там нет concurrent зато
но асинхронное ожидание асинк уже позволяет сделать
Б
а еще он позволяет сделать liftIO
AS
Интересно, искали там но не нашли, написали сами на Lagom, может тыкнешь пальцем где она там? ;-)
AS
А можно akka stream Source соединить с несколькими Sink-ами? Новый каждый N элементов. И при этом из каждого Sink наверх получить materialized value. SubFlow, которые возвращает подходящий свиду оператор
По сути мне надо Source по разным Sink-ам раскидать, которые пишут данные в файлы (и возвращают путь к файлу как materialized value). Чтобы было несколько файлов вместо одного большого.
splitWhen, - "cannot contribute to the super-flow’s materialized value since they are materialized later, during the runtime of the flow graph processing".По сути мне надо Source по разным Sink-ам раскидать, которые пишут данные в файлы (и возвращают путь к файлу как materialized value). Чтобы было несколько файлов вместо одного большого.
AH
А можно akka stream Source соединить с несколькими Sink-ами? Новый каждый N элементов. И при этом из каждого Sink наверх получить materialized value. SubFlow, которые возвращает подходящий свиду оператор
По сути мне надо Source по разным Sink-ам раскидать, которые пишут данные в файлы (и возвращают путь к файлу как materialized value). Чтобы было несколько файлов вместо одного большого.
splitWhen, - "cannot contribute to the super-flow’s materialized value since they are materialized later, during the runtime of the flow graph processing".По сути мне надо Source по разным Sink-ам раскидать, которые пишут данные в файлы (и возвращают путь к файлу как materialized value). Чтобы было несколько файлов вместо одного большого.
Броадкаст там был где-то
AS
Броадкаст там был где-то
Там фиксированный number of output ports. 🤷♂️
AH
Там фиксированный number of output ports. 🤷♂️
I
По моему, между Saga & FSM мало общего :)
AS
По моему, между Saga & FSM мало общего :)
А как иначе реализовать принцип конечного автомата без конечного автомата?
Saga - это ж паттерн переходов из состояний в состояния по определенным правилам. В случае ошибки - порядок и правила вызовов обратных действий.
Saga - это ж паттерн переходов из состояний в состояния по определенным правилам. В случае ошибки - порядок и правила вызовов обратных действий.
AS
если X - это обозреваемый эффект работы приложения, т.е. от различий в X ты судишь о различии в работе приложения, то нужно оборачивать
Тут легко сказать что аллокации надо поворачивать тк нет памяти и ниче не работает
С другой стороны нам на логи может быть сильно насрать и это не является частью работы приложения
Ну в общем это и так и так можно применять.
Если адекватно - то большинство логов это не часть работы приложения. Те которые критичные (потом нужны для разбора инцидентов) то может быть. Но не понятен профит. Я никогда не видел чтобы логи падали или тупили как ио в базу и тогда не совсем понятно зачем оборачивать
С другой стороны нам на логи может быть сильно насрать и это не является частью работы приложения
Ну в общем это и так и так можно применять.
Если адекватно - то большинство логов это не часть работы приложения. Те которые критичные (потом нужны для разбора инцидентов) то может быть. Но не понятен профит. Я никогда не видел чтобы логи падали или тупили как ио в базу и тогда не совсем понятно зачем оборачивать
DM
Тут легко сказать что аллокации надо поворачивать тк нет памяти и ниче не работает
С другой стороны нам на логи может быть сильно насрать и это не является частью работы приложения
Ну в общем это и так и так можно применять.
Если адекватно - то большинство логов это не часть работы приложения. Те которые критичные (потом нужны для разбора инцидентов) то может быть. Но не понятен профит. Я никогда не видел чтобы логи падали или тупили как ио в базу и тогда не совсем понятно зачем оборачивать
С другой стороны нам на логи может быть сильно насрать и это не является частью работы приложения
Ну в общем это и так и так можно применять.
Если адекватно - то большинство логов это не часть работы приложения. Те которые критичные (потом нужны для разбора инцидентов) то может быть. Но не понятен профит. Я никогда не видел чтобы логи падали или тупили как ио в базу и тогда не совсем понятно зачем оборачивать
жаль что не видел, явно не любитель контейнеров
VP
кто в курсе чего там с лайтбендом? много народу сегодня ливнуло 🤔