Гарантирует ли CloudKit, что CKRecord.Reference всегда действителен? ⇐ IOS

[Anonymous]

Я подумываю об использовании CloudKit в своем приложении (оно не использует Core Data) и прочитал столько материалов, сколько смог найти. Я еще не до конца это понял, и у меня есть основной вопрос по CKRecord.Reference. Гарантирует ли CloudKit, что значение CKRecord.Reference всегда допустимо? Под действительным я подразумеваю, что целевой CkRecord, на который указывает CKRecord.Reference, существует в базе данных.
Давайте рассмотрим пример. Предположим, есть две таблицы: Счет и Транзакция:

Код: Выделить всё

Account Table:

AccountNumber Currency Rate
------------- -------- ----
a1            USD      0.03

Transaction Table:

TransactionNumber AccountNumber Amount
----------------- ------------- ------
t1                a1            20

Теперь предположим, что пользователь делает следующее:

• Пользователь сначала удаляет учетную запись a1 и связанные с ней транзакции t1 на устройстве A. Устройство сохраняет изменения в облаке.
• Затем пользователь добавляет новую транзакцию t2 в учетную запись a1 на устройстве B, < em>до того, как устройство получит изменения, сделанные на шаге 1, из облака. Поскольку a1 не был удален на устройстве B, операция должна завершиться успешно локально. Устройство также пытается сохранить изменения в облаке.

Мои вопросы:
Q1) Сможет ли устройство B сохранить изменения, полученные на шаге 2, в облаке?
Я надеюсь, что это не удастся, потому что в противном случае это приведет к противоречивым данным. Но я нашел следующее в документе CKModifyRecordsOperation (выделено мной), что подразумевает, что CloudKit допускает недопустимую ссылку:

Во время операции сохранения CloudKit требует, чтобы целевая запись родительской ссылки, если она установлена, существует в базе данных или является частью той же операции; все остальные справочные поля освобождаются от этого требования.

(Кстати, я думаю, тот факт, что при использовании CloudKit, Core Данные требуют, чтобы все связи были необязательными, а также указывает на то, что CloudKit не может гарантировать, что связь всегда действительна, хотя я думаю, что это в основном проблема на стороне клиента, вызванная размером передаваемых данных. Однако приведенный выше пример отличается тем, что это проблема. на стороне облака - данные в облаке противоречивы).
Я также нахожу в документе следующее. Однако я не думаю, что это поможет в приведенном выше примере, поскольку IIUC CloudKit может обнаружить конфликт только тогда, когда изменения в одной и той же записи, но изменения на шаге 1 и шаге 2 находятся в разных записях.

Поскольку записи могут меняться между моментом их получения и моментом их сохранения, политика сохранения определяет, будут ли новые изменения перезаписывать существующие изменения. По умолчанию операция сообщает об ошибке, когда на сервере имеется более новая версия.

Однако, если приведенное выше понимание верно, я не понимаю почему в одном и том же документе есть следующее требование, подразумевающее, что CloudKit не допускает недопустимых ссылок:

При создании двух новых записей, между которыми есть ссылка, используйте одна и та же операция для одновременного сохранения обеих записей.

Q2) Предположим, CloudKit допускает недопустимую ссылку на стороне облака (что то есть устройство B успешно сохраняет изменения на шаге 2 в облаке). Интересно, как лучше всего с этим справиться?
Я думаю, что проблема отличается от необязательного требования отношения в Core Данные при использовании CloudKit, потому что в этом случае данные согласованы на стороне облака, и в конечном итоге клиент получит полные данные. Однако в приведенном выше примере данные в облаке противоречивы, поэтому клиент должен каким-то образом это исправить (хотя у клиента мало информации, которая может помочь).
Один из подходов, о котором я думаю, — избегать вопрос на первом месте. Моя идея состоит в том, чтобы поддерживать счетчик в базе данных и требовать от клиента увеличения счетчика (это не часы Лампорта. Кстати, можно ли в этом случае использовать часы Лампорта?) При внесении каких-либо изменений. Это должно помочь CloudKit обнаружить конфликт (хотя я не могу придумать хорошую стратегию того, как клиент должен с этим справляться. Самый простой вариант — предложить пользователю выбрать одну копию). Однако этот подход эффективно использует облако в качестве централизованного сервера, что, как я подозреваю, не является типичным способом использования CloudKit и требует от клиентов поддерживать значение локального счетчика в различных ситуациях. Интересно, каков типичный подход? Я что-то упустил?
Спасибо за любую помощь.

Подробнее здесь: https://stackoverflow.com/questions/791 ... ways-valid