i'm not sure why, but if i remove that part, and just pattern match on the result then i get everything working as normal
if not, then i get nothing written in the database
my guess is that the Functor for
I that cata needs is some how messed up
mapping when i should have been flatMapping, which was hidden by the any to Unit + turning off the value discard warning
plus,
cata can't do what i want
figured the issue out by unrolling what
cata does
Yeah,
-Ywarn-value-discard is super helpful, especially when used along with -Xfatal-warnings
Saved me many times. Debugging value discard related bugs can get pretty nasty sometimes
in general i like the auto-unit conversion that scala does
i do wonder though for when you want effects if it wouldn't make sense to have a separate placeholder, like say Akka does with
NotUsed I think it is, for when you really intend to have no action
an ergonomics + bike shedding issue for sure
scala-steward is great, but the amount of spam it generates is unbelievable 🙂
Oh, and by the way. I'm currently working on some basic saga support for Aecor and it seems that I will need to make saga's algebra shape as
Saga[F[_], D] - and that's because it should provide some create(data: D): F[Unit] capability (every user's concrete saga implementation may operate on a different data type passed around)
It turns out that kind-projector allows to handle that case even with the existing
EventsourcedBehavior, but my question is whether you would consider that an acceptable design at all?
Namely the
Saga[F[_], D] shape that will have an existing EventsourcedSaga[F[_], D] implementation, provided by the library out of the box, and the only thing that the user cares about is to specify the saga's flow (and wire everything, of course), with some DSL such as:step {
attempt { data =>
// we call some specific entity:
warehouses(...).markForDeparture(...)
}
.handleFailWith { data =>
warehouses(...).cancelDeparture(...)
}
.commitWith { data =>
warehouses(...).issueGoods(...)
}
// both handleFailWith and commitWith are optional
}
.step {
attempt { data =>
shops(...).reserveSpace(...)
}
// (...)
}
@heksesang I haven't been working on it recently, quite frankly. I've got a few doubts when it comes to saga's design in Aecor - wanted to discuss that with Denis first, but it seems that he's not available on Gitter that often (I remember he's mentioned to be quite busy these days)
The thing is that the whole saga mechanics is based on
EventsourcedBehavior, as Denis once suggested, but the whole interaction with it might feel a bit hacky, I would say...? And that's because EventsourcedBehavior wasn't introduced with Saga[F[_], D] shape in mind, obviously. I'm not entirely sure whether the final version done this way could end up being merged into the Aecor's master, as it might not fit the rest of library's "zen". I haven't pushed the current POC to my fork, as it still requires major clean-up
The whole Aecor, when it comes to behavior execution on top of Akka and its event-sourcing support, comes down to those traits and classes revolving around
T[F[_]] algebras and EventsourcedBehavior, so it seems that reusing existing blocks should be the way to go - possibly with some tweaks here and there. The alternative would carry much more work to be done. Anyhow, I would rather discuss saga's design premises before raising any PR
One could use saga pattern in Aecor right now - you just need to create bunch of entities and processes. My approach was to minimize the amount of boilerplate needed to encode saga's flow as well as provide transitions mechanics out of the box, so that the end user doesn't need to worry about it. Generally speaking, the only thing that needs to be defined by the user is the saga's flow DSL (as in my snippet above). This way the main saga logic (provided by the library) has to be as generic as possible. Thus the
D type parameter in question, that represents any data type that the particular saga operates on. It's data type from the DSL snippet
@notxcain I feel like you could compete with https://github.com/uber/cadence/ if you combined your scheduling stuff and extended the ActionT runtime to have more functionality (like some native events on top of serialized events)