В таблицу pgis2map_dbchanges_log сохраняется информация о том, в какой таблице, какая запись когда и кем крайний раз редактировалась.
Помимо этого регистрируется
идентификатор приложения, выполнившего изменения (sessionident
SpatialDB Service принудительно устанавливает себе такой идентификатор при работе с БД, а затем игнорирует все записи в журнале pgis2map_dbchanges_log с таким идентификатором, так как считает это своими изменениями.
Это сделано для минимизации операций записи на карту, так как в противном случае изменения, сделанные на карте, SpatialDB Service вначале перенесет в БД, а затем, увидев соответствующую запись в журнале и не отделив свои транзакции от сторонних, будет вынужден вновь выполнить запись этих изменений на карту.
Насколько я понял, проблема как раз с операциями, выполняемыми самим SpatialDB Service. С изменениями извне проблем нет, судя по Вашим словам:
Цитата |
---|
er35 написал: Изменения выполненные разными приложениями синхронизируются в обе стороны |
Для фиксирования изменений в таблице журнала SpatialDB Service - pgis2map_dbchanges_log на каждую таблицу с пространственными данными устанавливается триггер.
По умолчанию это делается штатным скриптом, входящим в инсталляцию. Этот скрипт создает триггеры на все таблицы, где есть поле метрики и поле первичного ключа.
Далеко не всегда все эти таблицы должны быть задействованы для SpatialDB Service. Конечный состав определяете Вы.
Никто не запрещает Вам изменить логику триггера по своему усмотрению. Даже более того - это как раз возлагается на Вас. SpatialDB Service требует лишь наличие определенным образом заполненного журнала pgis2map_dbchanges_log, а как именно он будет заполняться, определяется логикой той системы в рамках которой используется SpatialDB Service. Скрипт, создающий триггеры на все подряд пространственные таблицы, включен в состав SpatialDB Service только для удобства и в качестве примера.
Цитата |
---|
er35 написал: а) будут ли эти изменения все-таки попадать в карту на ГИС сервере? |
Будут, если будут соблюдены условия по регистрации изменений в таблице-журнале (pgis2map_dbchanges_log).
Цитата |
---|
er35 написал: б) не попортит ли ручная правка pgis2map_dbchanges_log какой либо механизм? |
Попортить механизм таким образом можно только в части повторной записи данных на карту в результате изменений на самой же карте (см. выше). Но, судя по всему, это Вам как раз и требуется.
Зацикливания не произойдет. SpatialDB Service при следующем запросу изменений данных на ГИС Сервере отфильтрует свои транзакции и опять они в БД записываться не будут.
Однако, я рекомендовал бы не создавать второй триггер, который обновит Ваши поля и еще раз сделает INSERT в таблицу pgis2map_dbchanges_log, а изменить существующий, который в том случае, если Вам необходимо, чтобы SpatialDB Service еще раз обработал только что измененную запись, фиксировал бы изменение в pgis2map_dbchanges_log без сохранения идентификатора транзакции, а в остальных случаях работал штатно.
Иначе, во-первых, необходимо обеспечить гарантированное срабатывание Вашего триггера именно после того, как отработает штатный триггер, а во-вторых, - зачем Вам выполнять дважды запись в pgis2map_dbchanges_log?
На всякий случай, выдержка из документации:
Скрытый текст |
---|
Для реализации возможности инкрементной обработки в базу данных должна быть добавлена служебная таблица – журнал изменений, в которой регистрируются все факты изменений в таблицах БД, подлежащих нанесению на карту. Регистрация фактов изменений производится специальными триггерами этих таблиц. Факт создания, изменения или удаления каждой записи вносится в журнал изменений с указанием кода операции и времени ее совершения. Каждая запись находит отражение в журнале изменений лишь единожды. То есть если запись была изменена, а затем удалена, то в журнале факт изменения будет замещен более поздним по времени фактом удаления. Таким образом, максимальное количество записей в журнале изменений будет равно суммарному количеству всех записей (включая удаленные) всех таблиц, регистрирующих свои изменения в этом журнале. При записи в БД изменений, выполненных пользователями ГИС Сервера SE, регистрируется уникальный идентификатор сессии. Таким образом, добавленные, измененные или удаленные записи БД в ходе указанных действий помечаются в журнале изменений определенным образом и при последующем переносе изменений из ОО БД на карту пропускаются. Это позволяет избежать повторного редактирования объектов на карте. |