Я создаю простую базу данных рекордов для игры для iPhone, используя Amazon SimpleDB, и сталкиваюсь с некоторыми странными проблемами, когда ответные сообщения SimpleDB, кажется, не совпадают с запросами, которые я посылаю, или даже с состоянием данные на сервере.
Ожидаемая последовательность событий для отправки рекордов в приложении:
Запрос PutAttributes создан
который пытается перезаписать текущий
оценка с новым значением, но только если
это больше, чем последний известный
значение оценки.
Если ожидаемое значение не соответствует значению на сервере, в ответном сообщении SimpleDB приложение узнает, что такое действительное значение, и создается новый запрос, используя его в качестве нового ожидаемого значения.
Этот процесс продолжается до
ответ гласит, что все
было хорошо или пока счет на
сервер возвращается как выше, чем
счет, который мы пытаемся представить
(т.е. если кто-то с более высоким
счет представлен в то время как это
вперед и назад продолжалось)
(Если это уместно, я использую класс ASIHTTPRequest для обработки запросов, и я явно отключил кэширование, установив политику кэширования каждого запроса на ASIIgnoreCachePolicy при их создании.)
Однако то, что на самом деле происходит, немного странно ...
Первый ответ возвращается с ожидаемым результатом. Например, приложение отправляет оценку 200 и ожидает, что оценка на сервере будет равна 0, но на самом деле она равна 100. SimpleDB отвечает, что условная проверка завершилась неудачно, и позволяет приложению узнать фактическое значение на сервере (100).
Приложение отправляет запрос с обновленным ожидаемым значением, но SimpleDB отвечает идентичным ответом, как в первый раз, даже если ожидаемое значение было изменено (например, в ответе указано, что фактическое значение равно 100 и ожидаемое значение, которое мы передали in было 0, хотя мы только что изменили его на 100).
Приложение отправляет третий запрос с точно такими же оценочными / ожидаемыми значениями, что и второй запрос (например, 100 для обоих), и SimpleDB сообщает, что условие снова не выполнено, поскольку фактическое значение равно 200.
Похоже, что вторая попытка действительно сработала, хотя SimpleDB сообщил об ошибке и неверно описал параметры, которые я передал. Это странное поведение также очень непротиворечиво - каждый раз, когда я пытаюсь обновить счет с ожидаемым значение, которое не соответствует значению на сервере, происходит точно такая же последовательность.
Я уже некоторое время ломаю голову над этим, и у меня нет идей, поэтому, если кто-то с большим опытом работы с SimpleDB, чем я, мог бы пролить свет на это, я был бы очень благодарен.
Ниже приведен пример последовательности запросов и ответов на случай, если лучше описать ситуацию лучше, чем мое измученное объяснение выше (эти значения взяты из реальных запросов и ответов, но я отредактировал не относящиеся к делу части запросов).
Запрос 1
(Оценка на сервере 100 на данный момент)
Attribute.1.Name = Score
Attribute.1.Replace = верно
Attribute.1.Value = 200
Expected.1.Name = Score
Expected.1.Value = 000
Последовательная = верно
Ответ 1
Условная проверка не пройдена. Значение атрибута (балла) равно (100), но ожидалось (000)
Запрос 2
(Приложение обновляется до нужной оценки, но на основании ответа SimpleDB, похоже, игнорирует изменения)
Attribute.1.Name = Score
Attribute.1.Replace = истина
Attribute.1.Value = 200
Expected.1.Name = Score
Expected.1.Value = 100
Последовательная = верно
Ответ 2
Условная проверка не пройдена. Значение атрибута (балла) равно (100), но ожидалось (000)
Запрос 3
(На этот раз SimpleDB правильно получает ожидаемое значение, но также сообщает, что оценка была обновлена, хотя все предыдущие ответы указывали иначе)
Attribute.1.Name = Score
Attribute.1.Replace = истина
Attribute.1.Value = 200
Expected.1.Name = Score
Expected.1.Value = 100
Последовательная = верно
Ответ 3
Условная проверка не пройдена. Значение атрибута (балла) равно (200), но ожидалось (100)
Обновление (21.10.10)
Я проверил, чтобы убедиться, что идентификаторы requestID, которые возвращаются с сервера, являются уникальными и действительно являются.