Open ktoso opened 9 years ago
Some additional (overlapping) input.
Rewriting the persistent event history is not encouraged, but sometimes needed. E.g.
This probably a tool that is run offline with real system shutdown.
Such a tool would be great. Here are some thoughts how and why I would use such a tool in my current project.
Confirm
-Messages introduced by a workaround explained here. (Option b: Join streams using AtLeastOnceDelivery in individual persistent actors to a "topic" aggregator.)Hope this helps to tailor the implementation if you decide to support such a tool.
almost forgot:
@michaelom thanks for great feedback
The first custom query I implemented was the all events (aka event firehose), this makes a lot of sense.
Something else to consider is possibly exposing the write side of journals as a sink, mapping the event envelopes into atomic writes.
I agree that a stream based PersistentWriter
would be nice. Also mentioned in #15667
I think the building blocks are in place to implement this, and can also be done by end user (or external library). A PersistentActor
can work as the writer, and integrate with streams using mapAsync
and ask
.
Technically may be revisited once we revisit "projections" tooling so keeping this open even though inactive since a while. Feel free to close if that would be better tho
Just an idea for now, but perhaps a rather useful one.
The following question comes up sometimes on akka-user: "I need to change my journal, because X-DB sucks and I need to use Y-DB now". Using the new read side we could simply "read all events" and store them to the other journal.
This depends on two features:
With the above two things in place, this should be rather simple to implement - or document.