CODEWITHSUNDEEP
javascriptentity-frameworkasp.net-web-apitransactionsbreeze
mikesigs
mikesigs

Reputation: 11420

Non-Transactional SaveChanges with Breeze.js

Imagine you have a UI that consists of a list of items, each with a checkbox beside them. You can select multiple checkboxes and click a button to perform a bulk operation. The desire is to have as many of the rows be processed as possible. So if one row fails, the other selected rows should not roll back.

To do this with Breeze, would it make more sense to send multiple different saves, or is there a way to handle this scenario out of the box?

Sorry. I am new to Breeze, and have been looking through the docs, samples, and API and can't see any clear indication that this is possible. It appears that each call to SaveChanges is transactional. Or is a Named Save required to achieve this behavior?

Thanks in advance!

Upvotes: 0

Views: 126

Answers (1)

Ward
Ward

Reputation: 17863

There is no simple way to do a non-transactional batch save in Breeze. You're easiest course is to save each change individually. You can fire them off in parallel and wait for all to complete if that's important to you.

However, if you're game for some serious programming, it can be done. Here is the outline of the approach.

How to write a non-transactional batch save in Breeze

The easy part is turning off the transaction on the server.

Take a look at the second parameter of ContextProvider.SaveChanges. It's a Breeze TransactionSettings object. If you "new" that up you'll get this

public TransactionSettings()
{
  this.IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted;
  this.Timeout = TransactionManager.DefaultTimeout;
  this.TransactionType = TransactionType.None;
}

You can change create one with any value you like but I'm calling attention to TransactionType.None.

Pass that in your call to SaveChanges

    [HttpPost]
    public SaveResult SaveChanges(JObject saveBundle)
    {
        return _contextProvider.SaveChanges(saveBundle, myTransactionSettings);
    }

I believe that will prevent the EFContextProvider from saving transactionally.

Now you have to fix things on the client side. I haven't turned off transactions so I'm not familiar with how errors are caught and transmitted to the client.

The real challenge is on the client. You have to do something when the save fails partially. You have to help the Breeze EntityManager figure out which entities succeeded and which failed and process them appropriately ... or your entity cache will become unstable.

You will have to write a custom Data Service Adapter with some very tricky save processing logic. That is not easy!

I've done it in my Breeze Labs Abstract Rest Adapter which is not documented and quite complex. You're welcome to read it and apply its reasoning to your own implementation of the "web api" Data Service Adapter. If you have budget, you might engage IdeaBlade professional services (makers of Breeze)

Upvotes: 1

Related Questions