При использовании Ember.js с REST-адаптером ember-data существует ли какая-то стратегия разрешения конфликтов для обработки сохраняющихся данных на сервере?
По крайней мере, в моем случае сбоя и отката было бы достаточно в случае конфликтов, если пользователь может быть проинформирован об этом. Итак, потребуются ли для этого какие-то данные/структура? Какой-то идентификатор «версии» в моделях, где сервер может проверить представленные версии и убедиться, что у клиента есть самые последние данные. Есть ли что-нибудь в Ember.js, чтобы сделать это немного менее ручным? И если да, то что?
Изменить: Кроме того, есть ли что-нибудь, что помогает с конфликтами массовых коммитов моделей? Скажем, у нас есть родительская модель с отношением hasMany к нескольким дочерним моделям, и все они должны быть одновременно сохранены в базе данных. Если иметь дело только с кодом на стороне сервера, я чувствую, что могу обернуть это транзакцией в любой базе данных, которую я использую, и потерпеть неудачу, если что-то устарело. Как это отразится на транзакциях Ember.js?
Я вижу флаг bulkCommit в классе адаптера. Кажется, это позволяет массово фиксировать объекты одного типа в одном запросе. Однако, если я сохраняю записи более чем одного типа, это приведет к нескольким запросам к серверу. Есть ли способ либо а) сделать это одним запросом к серверу, либо б) сопоставить транзакции ember-data с транзакциями на сервере, поэтому, если транзакция на сервере не удалась и ее необходимо откатить, транзакция ember-data также не работает?
[Я оцениваю Ember.js для предстоящего проекта и тестирую несколько функций и то, на что похоже разработка. На самом деле я рассматриваю возможность большего количества обновлений в реальном времени с использованием socket.io или аналогичного. Я вижу, что derby.js сделал некоторые шаги в сторону автоматического разрешения конфликтов]
