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

Cosmos DB saga storage #923

Open
gideonkorir opened this issue Jan 4, 2021 · 8 comments
Open

Cosmos DB saga storage #923

gideonkorir opened this issue Jan 4, 2021 · 8 comments
Assignees
Projects

Comments

@gideonkorir
Copy link

Similar to this previous issue. I'd like to run rebus on Azure with Cosmos DB rather than use SQL Server since we are using currently using cosmos for all our data storage.

I've been looking into it and have an implementation here.

So far this is what I've come up with:

  1. Partitioning by some correlation property (e.g. OrderId) means that looking up the saga data by any other correlation property will lead to a cross partition query. My current implementation only supports a single correlation property and throws if multiple properties are specified. This means all tests in Rebus.Tests.Contracts that have multiple correlation properties will fail.
  2. Partitioning by saga data type (or some value derived from it) allows multiple correlation properties since we always know the partition key but will use up more RUs since we won't be doing a point query unless we are using the id property.

I've checked the MassTransit saga persistence and Nservicebus saga persistence and they all seem to be using (1) above.

Using (2) might be ok if one is ok with limits of a single partition

@mookid8000
Copy link
Member

I'd definitely go for (1).

Regarding the tests, maybe it would make sense to simply not use the contract tests for this persister.

Or maybe it would make sense to split the contract tests out into separate fixtures for single-property and multi-property correlation scenarios, which would then make it possible for single-property persisters to include only the tests they can work with....?

@gideonkorir
Copy link
Author

I have implemented both options (I was thinking that (2) might be better for someone migrating from other stores and they are ok with the limitations + it was quite simple to implement).

On the tests for (1) I copied over the contract tests and modified the correlation to get them to work. It was pretty straightforward.

I've pushed all the code + tests here.

@mookid8000 mookid8000 added this to Assess in Rebus via automation Jan 22, 2021
@mookid8000 mookid8000 self-assigned this Jan 22, 2021
@TimterLaare
Copy link

TimterLaare commented Aug 30, 2021

I would love this feature in a future release! @mookid8000 What is the status of this issue?

@mookid8000
Copy link
Member

Not sure 🙂 @gideonkorir does it work for you?

@gideonkorir
Copy link
Author

@mookid8000 I didn't get to use it in production :( but it was working for all initial tests that I had though I'd be happy to collaborate to get it in a good state

@TimterLaare
Copy link

@gideonkorir @mookid8000 Which steps need to be taken to get this implemented?

@mookid8000
Copy link
Member

Hi @gideonkorir , did your CosmosDB saga persister work as expected? Would you be interested in contributing it to rebus-org?

@mookid8000 mookid8000 moved this from Assess to Awaiting reply in Rebus Oct 12, 2021
@gideonkorir
Copy link
Author

@mookid8000 The persister worked as expected for my local testing but as I discussed before I never got the chance to use it in prod. I am happy to contribute it to rebus-org let me know what I need to do :)

@TimterLaare the testing bit is what maybe needs improving I am not sure what other test cases I need to cover in order for them to be considered complete. I am also not generating a nuget package right now

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

No branches or pull requests

3 participants