Синхронизация с НГВ

Введение

В данном документе изложен принцип синхронизации, который реализовано в NextGIS maplib for android v2.1.

Общие сведения

Схема работы с НГВ следующая:

1. В локальную систему закачивается весь слой и сохраняется во внутреннем формате. Сохраняется описание слоя - тип геометрии, структура полей, а также идентификатор слоя в НГВ, url НГВ, логин и пароль пользователя
2. При изменении слоя, если он отмечен как синхронизируемый с НГВ, создаются пакеты правок. Пакет правок, это информация о действиях (создание, удаление, изменение) которые были выполнены над записью. Кроме того, пакет может содержать правки для вложений (аттачментов, фото).
3. При синхронизации вначале получаются данные с сервера и вносятся необходимые изменения в слой
4. После принятия правок от сервера на него передаются локальные правки.

Пакет правок

В слое заведен массив пакетов правок. Пакет правок содержит:

• идентификатор записи
• операцию, которая была произведена над записью (создание, изменение, удаление)

Также в пакете содержится массив пакетов правок вложений, который аналогичен пакету правок записи, но содержит идентификатор вложения. Для новых записей и вложений идентификаторы начинаются с 10000000 для исключения пересечения идентификаторов НГВ и локальных.

При выполнении операций над записью в массив добавляется новый пакет. Если для записи пакет уже существует, то он модифицируется. Не допускается иметь несколько пакетов для одной записи (вложения).

При изменении пакета действуют следующие принципы. Для операции удаления производится создание или изменение ранее созданного пакета. Для операции создания производится вызов assert, т.к. такой ситуации быть не должно (дважды, трижды и т.д. создания одной и той же записи). Для изменения - если имеется предыдущая операция, то ничего не меняется, т.к. если пользователь вначале создал запись, а потом ее изменил, то в НГВ должно быть выполнено именно создание записи с актуальными атрибутами и геометрией, а изменение невозможно (записи еще нет в НГВ).

Аналогичные принципы действуют для вложений.

Синхронизация с сервером

Получение записей с сервера

С сервера получается JSON с данными слоя:

http://<ngw_url>/api/resource/<resource_id>/feature/

Из JSON извлекаются записи (атрибуты, геометрии, наличие вложений). Для каждой записи с сервера ищется соответствующая локальная запись по идентификатору.

Если запись не найдена, то проверяется массив пакетов правок. Если в массиве нет операции удаления для идентификатора записи, то создается новая запись. Иначе производится переход к следующей записи.

Если локальная записи найдена, то записи (локальная и с сервера) сравниваются - вначале атрибуты, потом геометрии, потом вложения.

Если записи идентичные то производится переход к следующей записи, иначе проверяется массив пакетов правок. Если в массиве есть пакет для записи, то производится переход к следующей записи. Иначе изменения с сервера применяются к записи.

Передача записей на сервер

После обработки данных с сервера производится итерирование по оставшимся пакетам правок:

• Если операция удаления, то запись с соответствующим идентификатором удаляется с сервера.
• Если операция изменения, то запись с соответствующим идентификатором обновляется на сервере.
• Если операция создания, то на сервере создается новая запись. В результате успешного создания сервер возвращает идентификатор, которой назначается локальной записи, по которому осуществляется связь локальной записи и записи на сервере.

Вложения

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

При создании нового вложения сервер возвращает его идентификатор, который назначается локальному вложению вместо автоматически назначенного 1000+. После этого локальное вложение и вложение на сервере становятся связаны по этому идентификатору.

Заключение

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

• загружать с сервера только измененные данные слоя, а не весь слой
• сравнивать временные метки изменений, а не записи