You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Akka Persistence has added a Durable State persistence mode; should Cassandra support it?
Details
The JDBC/R2DBC plugins support Durable State, which suggests at least some investigation should be performed around supporting it in this plugin.
One possibility, matching the approximate usage pattern of Durable State with relational stores would be to write with ALL consistency and read with ONE consistency: this somewhat matches up with the general contrast in Durable State from Event Sourcing of optimizing for the read (typically smaller and faster with Durable State) over the write (typically larger and slower with Durable State). Doing it this way would also make it more likely to be "eventually update-in-place" and reduce storage requirements: which also seems to be one of the main selling points for Durable State.
Alternatively, Durable State could be implemented along the lines of a generic StateUpdated event, but this seems to not provide any Durable State benefits beyond the simplicity of the developer API. Alternatively, this could be a generic "turn a generic event sourcing journal into a durable state store" that would also extend crude Durable State support to the other plugins in the community.
The text was updated successfully, but these errors were encountered:
Wouldn't durable state only really be expected to expose the durable state queries? The JDBC plugin doesn't seem to implement eventsBy* for durable state.
Short description
Akka Persistence has added a Durable State persistence mode; should Cassandra support it?
Details
The JDBC/R2DBC plugins support Durable State, which suggests at least some investigation should be performed around supporting it in this plugin.
One possibility, matching the approximate usage pattern of Durable State with relational stores would be to write with
ALL
consistency and read withONE
consistency: this somewhat matches up with the general contrast in Durable State from Event Sourcing of optimizing for the read (typically smaller and faster with Durable State) over the write (typically larger and slower with Durable State). Doing it this way would also make it more likely to be "eventually update-in-place" and reduce storage requirements: which also seems to be one of the main selling points for Durable State.Alternatively, Durable State could be implemented along the lines of a generic
StateUpdated
event, but this seems to not provide any Durable State benefits beyond the simplicity of the developer API. Alternatively, this could be a generic "turn a generic event sourcing journal into a durable state store" that would also extend crude Durable State support to the other plugins in the community.The text was updated successfully, but these errors were encountered: