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

Support for TransactionalBatch #151

Open
catsburg opened this issue Dec 21, 2021 · 3 comments
Open

Support for TransactionalBatch #151

catsburg opened this issue Dec 21, 2021 · 3 comments
Labels
help wanted Extra attention is needed up-for-grabs 🙏🏽 Happy to consider a pull review to address this issue

Comments

@catsburg
Copy link

The repositories currently don't offer support for transactions (using TransactionalBatch), for use cases where a bunch of CRUD actions have to all succeed/fail together. If transactions are required, the only solution now is to implement a custom Repository, which kind of defeats the purpose of using this library.

It would be cool to be able to do something along the lines of:
await _repository.Batch(partitionKey).Create(item1).Replace(item2.Id, item2).ExecuteAsync();

@mumby0168
Copy link
Collaborator

mumby0168 commented Dec 22, 2021

Hi @catsburg, this is certainly a part of our plans myself & @IEvangelist where just chatting about it the other day. It might be required that we inject something other than IRepository<T> to deal with batches as a batch can span multiple IItems and current the IRepository<T> is scoped to one item in this libraries case, but I like the look of your API it certainly could be done and could ease some of the error handling when a batch fails. Like the idea 😃

@mumby0168
Copy link
Collaborator

Having a look at this and found this example, the question here is how can we make this API they already offer easier to use, just an open question, see here.

https://github.com/Azure/azure-cosmos-dotnet-v3/tree/master/Microsoft.Azure.Cosmos.Samples/Usage/TransactionalBatch

@catsburg
Copy link
Author

@mumby0168 Glad to hear that it's part of your plans!

Just to share some thoughts on this:

  • Enabling transactions over multiple IRepository<T>s might cause the following problems:
    • A transaction is scoped to a logical partition within a container, but multiple IRepository<T>s CAN use different containers. The only way to know for sure you're working with a single container, is when you have a single IRepository<T>.
    • Introducing a different objects for the transactions take away from the principle that a repository is supposed to control all CRUD operations for a given IItem
  • Implementing it on the IRepository<T> level will work just fine for one-type-per-container uses cases, and works fine for multiple-types-per-container use cases as long as the transactions involve just the one item type.
  • For the missing use case (multiple-types-per-container AND you want to do a transaction across multiple types): How relevant is this use case? Wouldn't there be something to say for IF you find yourself wanting to do this, you probably modeled your application poorly? Like for instance, you should denormalize further?

Hope this is useful! Pretty cool project you guys have, but unfortunately since we require transactions, we're not going to use it for now, and create our own Repositories instead .

@IEvangelist IEvangelist added help wanted Extra attention is needed up-for-grabs 🙏🏽 Happy to consider a pull review to address this issue labels Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed up-for-grabs 🙏🏽 Happy to consider a pull review to address this issue
Projects
None yet
Development

No branches or pull requests

3 participants