NEventStore / NEventStore.Persistence.MongoDB

Mongo Persistence Engine for NEventStore
MIT License
22 stars 26 forks source link

ObjectID used for Checkpoint (_id) field instead of client generated Int64 #59

Closed stevewgh closed 2 years ago

stevewgh commented 4 years ago

We make extensive use of NEventStore with MongoDB and the biggest issue we have is the generation of Checkpoint ID's on the client. When we scale our application across multiple clients there's a cut off point where adding more clients just equals more concurrency issues.

I understand that the integer based checkpoint allows a polling client to ask for changes > a known checkpoint (there may be other uses I'm not aware of). However, since MongoDB 3.6 there has been support for Change Streams (https://docs.mongodb.com/manual/changeStreams/) which can be used for the same purpose without being constrained to integers.

I'd like to change NEventStore.Persistence.MongoDB to allow the checkpoint (_id) field to be set by the database by using ObjectID instead of Int64. I think it could still be backwards compatible for existing stores (with use of the options class) but any polling client implementations would no longer work once the store started using the ObjectID types.

I'm happy to do this work myself and push to this repo, or I can create an entirely different persistence Nuget for NEventStore if you want to keep this one based on Int64?

AGiorgetti commented 3 years ago

Changing the checkpoint type requires some work on the core and all the providers.

Int64 was originally chosen because of the convenience in implementing SQL providers.

Creating a custom persistence is your best choice at the moment, I'll have to look into the interfaces and maybe provide a generic type for the checkpoint id.

stevewgh commented 3 years ago

Hi @AGiorgetti thanks for getting back to me. In the end we opted to create a custom persistence engine which migrated us onto a new target persistence model (not using MongoDb) so this is no longer a requirement for us. Please feel free to close the issue.