azure-cosmos-dotnet-repository
azure-cosmos-dotnet-repository copied to clipboard
Support for TransactionalBatch
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();
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 IItem
s 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 😃
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
@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 singleIRepository<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
- A transaction is scoped to a logical partition within a container, but multiple
- 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 .