Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Akka.Persistence.MongoDb v1.4.0 and Forward (Breaking Changes) #72

Closed
Aaronontheweb opened this issue Sep 24, 2019 · 2 comments
Closed
Labels
Milestone

Comments

@Aaronontheweb
Copy link
Member

Leaving a placeholder here - need to do a new Akka.Persistence.MongoDb release so we can ship #59 without introducing any additional breaking changes.

Once that's done I'll include my comments below.

This was referenced Sep 24, 2019
@Aaronontheweb
Copy link
Member Author

As I've discovered in the course of working on akkadotnet/akka.net#3744, the way we've been implementing Akka.Persistence serialization has not only been inconsistent plugin-by-plugin, but it's also been technically incorrect - and as a result, we've been able to properly support tools like Akka.Cluster.Sharding and their PersistentShard implementations in all Akka.Persistence plugins.

This issue stems from an unfortunate decision we made a long time ago to allow Akka.Persistence plugins to "do their own" thing with Akka.Persistence serialization so we could better take advantage of native drivers, queries, and so on. The alternative to this was following the original JVM design: treat the database like a simple event store and put all of the relevant serialization information inside a Protobuf envelope that was standard across all Akka.Persistence implementations. We chose the former, and the price we're paying is that Akka.Persistence's experience from plugin to plugin is different (features don't work properly or aren't supported) and it's negatively affecting users.

This is evidenced via #71 - the additional serialization specs in Akka.Persistence v1.3.14 can't pass under any configuration in Akka.Persistence.MongoDB. Ultimately if those can't pass, Akka.Persistence.MongoDB can't support the range of features Akka.Persistence is intended to support.

So as of akkadotnet/akka.net#3811, which will make it into either Akka.NET v1.4.0 or v1.5.0, we will be ditching object-based serialiation, for good, inside Akka.Persistence.MongoDB and moving to a protobuf envelope based format which will "just work" going forward.

FAQ

I still need object serialization because I'm querying the properties of stored objects directly in Mongo?

Then you should migrate off of Akka.Persistence altogether, because that behavior was never supposed to be supported in the first place and we won't be supporting in the future.

My boss requirements me to save all of our objects in a human-readable format in the database.

Akka.Persistence is meant to be an operational datastore, not an analytics / BI datastore. The data is purely meant for actors to park their state, recover it, and move it on the fly. Akka.Persistence.Query is designed to allow you to make projections of that state if need be. Don't use it if your requirements are different.

What am I supposed to do with all of my historically saved data in MongoDB?

We're going to work on that and see if it's possible, through the use of Akka.Peristence EventAdapters or something along those lines to provide forward compatibility for older events. Ideally, we would like to not have anyone stranded on an old version of Akka.Persistence and this is a problem we're going to have to solve across multiple plugins.

If you have any other questions, please leave them here.

@Aaronontheweb
Copy link
Member Author

Aaronontheweb commented Sep 24, 2019

We'll also come up with some fixes in the short run to ensure that all of your events are saved properly going forward (edit: prior to the arrival of any breaking changes) - and we're going to prioritize working on an upgrade path as part of this as well.

This is a problem we will need to solve across multiple plugins, so we'll come up with a solution that will work for MongoDB too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant