Ember.js data conflict resolution / non-conflict

Question

If you use Ember.js with a REST adapter with ember data, is there some kind of conflict resolution strategy to handle persistent data on the server?

At least for my case, in case of failure and rollback, it will be enough in case of conflicts if the user can be informed about this. So, will this require data or structure? Some kind of "variant" id on models where the server can check the presented versions and make sure that the client had the latest data. Is there anything in Ember.js to make this a little less manual? And if so, then what?

Edit: Also, is there anything that helps in mass model commit conflicts? Say we have a parent model with a hasMany relationship to multiple child models, and all of them must be stored in the database at the same time. If you are dealing with server-side code, I feel like I can wrap this in a transaction in any database that I use and fail if something is out of date. How does this translate to Ember.js transactions?

I see the bulkCommit flag in the Adapter class. Apparently, this may be an opportunity for mass execution of objects of the same type in a single request. However, if I save entries of more than one type, this will result in several requests to the server. Is there a way: a) to do this with a single request to the server or b) match transactions with ember data with transactions on the server, so if the transaction on the server fails and needs to be discarded, the transaction with ember data also does not work?

[I evaluate Ember.js for the upcoming project and test several features and what he likes to develop. I am really looking at more real-time updates using socket.io or the like. I see that derby.js has made some movement towards automatic conflict resolution]

Answer 1

As you can see in the Ember Data source code here , you can return 422 HTTP status code with errors as a dictionary. Errors will be added to the model by the Ember Data library by key as a property of the model, and the model itself will be considered invalid . The model will automatically leave this state after each property with errors changes to them.

You can watch for version errors and reloadRecord after a concurrency error occurs.