Версия строки базы данных OpenEdge

Я пытаюсь реализовать стратегию строковой версии для таблиц в нашей базе данных OpenEdge.

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

TRIGGER PROCEDURE FOR WRITE OF Customer OLD BUFFER oldCustomer.

IF Customer.iRowVersion < oldCustomer.iRowVersion THEN
  RETURN ERROR "RowVersion Out Of Date".

ASSIGN Customer.iRowVersion = Customer.iRowVersion + 1.

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

ASSIGN Customer.iRowVersion = NEXT-VALUE(rowVersionSequence).

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

Чтобы прояснить вопрос - было бы лучше увеличить номер версии строки на основе последней версии строки или следует использовать подход, подобный SQL, - делая каждую версию строки уникальной для базы данных.

Кроме того, будет ли триггер создания назначать начальную версию строки при переходе по стилю SQL? (в противном случае все новые неизмененные записи инициализируются с 0).


person Andrew Stalker    schedule 29.08.2017    source источник
comment
Нет ничего плохого в использовании для этого последовательности - если вы используете INT64 для поля версии, сомнительно, что вы когда-нибудь также переполните поле.   -  person Tim Kuehn    schedule 29.08.2017
comment
Есть ли где-то здесь вопрос?   -  person Tom Bascom    schedule 29.08.2017
comment
обновлен @TomBascom   -  person Andrew Stalker    schedule 30.08.2017
comment
То, что вы реализуете, называется оптимистической блокировкой, которую ProDataSets может делать довольно хорошо без необходимости прибегать к триггерам и полю версии.   -  person Tim Kuehn    schedule 30.08.2017
comment
Я вижу это здесь: documentation.progress.com/output/ua/OpenEdge_latest/, однако я не вижу такой возможности для работы со сторонними клиентами, подключающимися через AppServer без сохранения состояния. Если два клиента подключатся и захотят применить свои изменения, они оба будут считаться измененными, и один перезапишет другой, нет?   -  person Andrew Stalker    schedule 30.08.2017


Ответы (1)


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

Каждая таблица, в которой должна быть версия строки, будет иметь поле RowVersion типа Integer.

У нас есть программа, которая генерирует триггеры записи при создании новых таблиц, поэтому обновить ее для добавления нового кода было просто. Триггер записи теперь проверяет запись, чтобы увидеть, есть ли в таблице поле RowVersion, и если да, то увеличивает версию на 1. Проверка соответствия версии строки перед обновлением является обязанностью программиста в коде / сценарии, который они бегут.

У этого метода было несколько причин, но он упрощает:

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

  2. Последовательность не требуется для сохранения уникальности версий строк. Они не должны быть такими. Каждая запись просто увеличивает свою собственную версию строки.

  3. Хотя ProDataSets может выполнять оптимистическую блокировку, нет гарантии, что используемые записи всегда будут считываться / записываться с их использованием, и поэтому поле дает нам гибкость для написания различного кода в зависимости от использования.

  4. Обычно перед обновлением следует проверять версии строк. Если возникли проблемы с данными, может потребоваться запуск сценариев исправления для перезаписи данных в любом случае. Для этого мы оставляем проверку в вызывающей процедуре (а не в триггере) для операции записи в запись.

person Andrew Stalker    schedule 26.09.2018