На главную... Продукты | Технологии | Классификаторы | Проекты | Скачать | Цены| Форум | Статьи | Обучение | Контакты

Совместная работа Spatial DB и триггеров БД

Поиск  Пользователи  Правила  Войти
Форум » Серверные приложения » Panorama SpatialDB Service
Страницы: 1
RSS
Совместная работа Spatial DB и триггеров БД, Совместная работа Spatial DB и независимых триггеров в БД.
 
Имеем:
развернутый Spatial DB Service 3.3.0.5 на CentOS 7, который привязан к карте на ГИС Сервере. Изменения выполненные разными приложениями синхронизируются в обе стороны, однако есть одно "но". Есть площадной объект, который имеет количественный атрибут, необходимо получить плотность, т.е. поделить количество на площадь. Для выполнения этой операции в БД создан триггер, который работает на INSERT самого объекта, а также UPDATE полей геометрии и количества. Триггер отрабатывает нормально, изменения в БД вносятся, однако в карту на ГИС сервере они не попадают, видимо из-за того, что в таблицу pgis2map_dbchanges_log не вносятся изменения в результате работы триггера.

Вопрос:
Если после работы триггера вручную вносить изменения в pgis2map_dbchanges_log с типом редактирования записи 2 (UPDATE): а) будут ли эти изменения все-таки попадать в карту на ГИС сервере? б) не попортит ли ручная правка pgis2map_dbchanges_log какой либо механизм?
 
В таблицу 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?

На всякий случай, выдержка из документации:
Скрытый текст
 
Спасибо за ответ, но в целом уже разобрался. Мой вопрос скорее был в том, что я в любом случае буду создавать отдельный триггер самостоятельно. Ваш скрипт я уже видел, собственно я его запускал, чтобы в базе появилась таблица pgis2map...
Мой триггер срабатывает на определенные события и меняет некоторую информацию в отдельно взятой таблице. Моя задача состоит в том, чтобы эти изменения попали на ГИС сервер и, соответственно, на карту.
После появления записи об объекте в таблице pgis2map... я вручную меняю stamp и sessionident и после этого изменения попадают на ГИС сервер. Собственно теперь моя задача обновить pgis2map... в своем триггере. Думаю после этого все должно работать.
Правда возник вопрос: насколько я понял sdbs это идентификатор Spatial DB service. Всегда-ли после добавления объекта на карту, размещенную на ГИС сервере, запись попадает в pgis2map... с идентификатором сессии sdbs?
 
Цитата
er35 написал:
Собственно теперь моя задача обновить pgis2map... в своем триггере. Думаю после этого все должно работать.

Главное, в этом случае, чтобы Ваше обновление pgis2map_dbchanges_log было крайним.
И, опять же, нехорошо дважды на одну операцию выполнять запись/обновление в журнале.

Цитата
er35 написал:
Всегда-ли после добавления объекта на карту, размещенную на ГИС сервере, запись попадает в pgis2map... с идентификатором сессии sdbs?


Скажем так, если все хорошо, то да - запись всегда будет помечена неким идентификатором, назначенным SpatialDB Service.
Но, нет гарантии, что СУБД всегда позволит сервису это сделать. В этом случае идентификатор сессии будет не установлен и сервис будет обрабатывать все изменения, попавшие в журнал, - в том числе и свои.
Кроме того, не могу обещать, что идентификатором сессии всегда останется "sdbs". Это некая комбинация, которая позволяет воспринимать транзакции как свои. В следующих версиях, возможно, эту комбинацию придется изменить, либо ввести несколько комбинаций, либо могут быть еще какие-то изменения, - заранее трудно сказать.
Поэтому самый простой способ заставить сервис обновить на карте объект, даже если изменения в БД сделаны им самим, - это убрать для соответствующей записи в журнале идентификатор сессии совсем.
Страницы: 1
Читают тему (гостей: 1)



© КБ Панорама, 1991-2024

Регистрируясь или авторизуясь на форуме, Вы соглашаетесь с Политикой конфиденциальности