Хотелось бы иметь функцию IsOtherFieldsChanged

artemana
Дата: 16.07.2012 15:26:49
Добрый день!

Достаточно часто в триггере до\после изменения записи нужно проанализировать изменялось ли хоть одно из полей таблицы, кроме заданных. Сейчас нет другого способа как выполнить в лоб полное перечисление всех контролируемых полей. На пример,
  
if (New.Field1<>Old.Field1 or  (New.Field1 is not null  and  Old.Field1 is null) or  (New.Field1 is  null  and  Old.Field1 is not null) or
   New.Field2<>Old.Field2 or  (New.Field2 is not null  and  Old.Field2 is null) or  (New.Field2 is  null  and  Old.Field2 is not null) or
   
   ...
    )
  then execute procedure TestLockDate(....); 

Ф-ция coalesce может облегчать такой код, но все равно, перечисление всех полей, значение которых нужно контролировать, унылое занятие. Плюс при модификации состава полей таблицы нужно каждый раз не забывать подправлять такие громоздкие условия. Ведь суть проблемы в том, что такое условие касается всех полей таблицы за исключение одного или двух служебных, чья модификация разрешается в любом случае. Если бы не эти служебные поля, то вызов TestLockDate можно было бы делать безусловно. Но они есть, и хотелось бы в проверке отталкиваться от них, так как набор таких служебных полей в таблице невелик и редко меняется.

Неплохо было бы иметь функцию, которая могла бы вернуть результат булевого типа в зависимости от того менялись ли хоть одно поле в таблице или нет. В качестве параметров функция принимает имена полей таблицы которые нужно из проверки исключить. Функция может использоваться только в триггерах операции update.
Например, IsOtherFieldsChanged (AnyField4,AnyField5,...) возвратить true, если любое поле таблицы, кроме AnyField4 и AnyField5, изменило свое значение.

Какие будут мнения?
Dimitry Sibiryakov
Дата: 16.07.2012 15:30:15

artemana
Достаточно часто в триггере до\после изменения записи нужно проанализировать изменялось ли
хоть одно из полей таблицы

Ни разу не сталкивался с такой необходимостью.

Posted via ActualForum NNTP Server 1.5

pastor
Дата: 16.07.2012 15:32:52
artemana
Какие будут мнения?


в морг?
Oliph_
Дата: 16.07.2012 15:36:59
artemana,
Зачем coalesce?
Достаточно этого:
if (New.Field1 is distinct from Old.Field1
or New.Field2 is distinct from Old.Field2
   
   ...
    )
  then execute procedure TestLockDate(....); 
Esperito
Дата: 16.07.2012 15:42:08
artemana
Неплохо было бы иметь функцию, которая могла бы вернуть результат булевого типа в зависимости от того менялись ли хоть одно поле в таблице или нет.
Может лучше триггер для конкретных полей. Вроде такого:
CREATE OR ALTER TRIGGER MY_AU FOR MYTABLE ACTIVE AFTER UPDATE OF MY_COL_1, MY_COL_2
Или без списка полей, на каждое поле по триггеру.

Хотя нужно ли это всё...
Oliph_
Дата: 16.07.2012 15:48:46
artemana,
У меня текст большинства лог-триггеров генерируется автоматизированно,
путем построения тела триггера с перебором всех полей из метаданных для заданной таблицы.
В теле триггера проверяется измение каждого поля, к примеру:
if (new.STRNUM is distinct from old.STRNUM) then
            insert into log_fields(id_log, name, old_val, new_val) values (:id_log, 'STRNUM', old.STRNUM, new.STRNUM);
...
не представляю, как бы я это все ручками контролировал...
Все работает достаточно красиво, быстро, необходимости в подобной функции не испытываю.
artemana
Дата: 16.07.2012 15:55:16
Oliph_ и DS
Проявите фантазию, выйдите за рамками своих ежедневных задач!
Если сами ничего не придумаете, то приведу свои, ИМХО, достаточно обоснованные примеры, но чуть позже.
pastor
Дата: 16.07.2012 16:03:23
artemana
Oliph_ и DS
Проявите фантазию, выйдите за рамками своих ежедневных задач!
Если сами ничего не придумаете, то приведу свои, ИМХО, достаточно обоснованные примеры, но чуть позже.


а кто будет вставлять контроль НОВЫХ поля при изменении метаданных?

решение задачи есть - автоматическая перегенерация приложением при изменении метаданных. вводить из-за этого новую сущность (причем выходящую за рамки стандартов) желающих не будет.
artemana
Дата: 16.07.2012 16:09:22
pastor
а кто будет вставлять контроль НОВЫХ поля при изменении метаданных?

pastor, куда вставлять вы собрались?
pastor
Дата: 16.07.2012 16:35:04
artemana
pastor
а кто будет вставлять контроль НОВЫХ поля при изменении метаданных?

pastor, куда вставлять вы собрались?


я - никуда.

ВЫ - в анализ же.

Если есть список - то его надо как расширять, так и сужать. Изготовить тело триггера может или внешнее приложение или ХП с ES. Короче, УЖЕ есть более одного варианта решения, и заморачиваться ради третьего, ИМХО, не стоит.