| 0
- 09.02.2012 - 11:51
|
Доброе утро. Сижу, пытаюсь выстрелить себе в ногу ) Вобщем, есть таблица(ы), данные из которых удалять нельзя (как минимум 5 лет), но в тоже время необходимо всем показать, что кто-то их грохнул... Для этого придумал завести дополнительное поле..(is_delete_row), куда хотелось бы при попытке удаления заносить дату и время... ну, штобы не плодить таблицы-клоны для хранения удаленных данных, ибо данные будут удаляться крайне редко. Даже триггер написал на радостях. (оснорожно многа букав :) ) create or replace function trig_set_is_delete_row() returns trigger as $body$ begin old.is_delete_row = localtimestamp; /*и вот тут бы отменить удаление*/ return old; end; $body$ language plpgsql; ... но приплыл. Канешно можно после удаления восстанавливать запись инсертом... Но это криво как-то. (во первых - теряем вездесСущую универсальность триггера для кучи таблиц, во вторых у меня еще есть поле которое триггером вставляет дату создания записи :) ) Можно генерить исключение... это тоже не айс. Камрады, есть еще способы? Гугл не в курсе...     | | |
| 1
- 09.02.2012 - 13:21
|
Вобщем делаю универсальную триггерную хранимку для всех таблиц с инсертом после делита... Пофиг на поле "дата создания записи" буду фиотровать оносительно даты удаления. :( Хрень полная.... | | |
| 2
- 09.02.2012 - 13:41
|
Решение, что называется, в лоб: вместо таблиц использовать вьюшки и понавешать триггеров "instead of". P.S. Вьюшки нужны по той причине, что instead of не поддерживается на таблицах, а только на view. | | |
| 3
- 09.02.2012 - 13:57
| 3-CPU > Ок, можно попробовать... Но почти законил хранимку, сейчас допишу - протестю. Если устроит оставлю ее, т.к. уже почти готовое решение. Иначе буду пробовать через "instead of"... | | |
| 4
- 09.02.2012 - 15:01
|
Вот... получилось. Мож кому пригодиться... Триггер после удаления возвращает запись обратно, запихивая при этом в поле is_delete_row текущую дату. С каскадами (если дочерние таблицы не содержат указанного поля) пока не работает (удалит все). Времени мало. потом допилю. create or replace function trig_set_is_delete_row_after_delete() returns trigger as $body$ declare table_data_record record; sql_select character varying; sql_script character varying; old_value character varying; begin sql_select:=''; sql_script:=''; for table_data_record in (select col.column_name from information_schema.columns col where col.table_schema = quote_ident(TG_TABLE_SCHEMA) and col.table_name = quote_ident(TG_TABLE_NAME) order by col.ordinal_position) loop if length(sql_select) = 0 then sql_select:=sql_select||'($1).'||table_data_record .column_name; else sql_select:=sql_select||','||'($1).'||table_data_r ecord.column_name; end if; end loop; old.is_delete_row := localtimestamp; sql_script:= 'insert into '||TG_TABLE_SCHEMA||'.'||TG_TABLE_NAME ||' select '||sql_select; execute sql_script using old; return old; end; $body$ language plpgsql; | | |
| 5
- 09.02.2012 - 15:33
|
5-drmiller > А чего будет, если у тебя на такую таблицу будет еще триггер на insert? Он будет срабатывать при каждом delete, что может привести к некорректному поведению. | | |
| 6
- 09.02.2012 - 16:43
|
6-CPU >В таблицах, для которых предназначен этот триггер - обязательно есть поле "create_date", куда записывается время инсерта, т.е. фактически дата создания записи. Данный триггер при инсерте после делита будет писать в это поле то значение которое там и было. Сделовательно, для того чтобы небыло некорректного поведения + дата создания оставалась неизменной в триггере на инсерт нужно поставить маленькое условие: if new.create_date is null then new.create_date = localtimestamp; /*+ любые необходимые действия*/ end if; return new; При исерте из моего триггера new.create_date всегда будет not null. А все остальные инсерты (внетриггерные) - пройдут как надо. Да, согласен, код мягко говоря спецефичный... И требующий документации для тех кто будет это юзать. Но... в условиях бесконечной спешки и пинков для ускорения тщательно и хорошо делать не получаеца... :(( *пожаловался...типа* п.с. хочу чтобы в сутрах было 60 часов :)) | | |
| 7
- 09.02.2012 - 16:45
| Цитата:
| | |
| 8
- 09.02.2012 - 16:47
| Поле create_date было заведено, естественно, не ради реализации этого механизма, а как информация для отлавливания глюков в перерасчетах, и других операциях бизнес логики по данным из БД :) | | |
| 9
- 09.02.2012 - 21:29
|
от шо за люди? когда им без стеба советуют годное решение. они все равно пилят свое, кривоногий, храмое, сложное. ты подумай о тех, кто будет сопровождать это все. подумай о себе, что ты можешь споткнуться об трудноуловимый косяк, стоит чуть более требований навешать. вон cpu тебе ГОДНОЕ направление запилил. получишь простенькие, так сказать "линейные" инстед оф триггерки на вьюшках. просто, прозрачно, красиво, кашерно. нужное подчеркнуть. нет же, ты создал кривожопое, неочевидное, наверняка с подводными корнями решение. ну и зачем было вообще тему создавать? | | |
| 10
- 10.02.2012 - 12:33
| Цитата:
Хотя если бы это необходимо было только для одной таблицы - это наилучший вариант. Или я не прав? (что допустимо ибо о "instead of" впервые прочел только сегодня, и мож чего не уловил). Ну и... "все равно пилят свое, кривоногий, храмое, сложное". Пока глюков незамечено, ну и сложность вроде как тоже терпимая (одна ветка if в триггре искривляет прямую логику) :) Вся сложность восприятия лечиться комментом в одно меленькое предложение (для потомков и сочувствующих). м? | |
Интернет-форум Краснодарского края и Краснодара |
