передача дополнительных параметров в insert/update postgresql

Question

[Владимир Коровин]

Доброго времени!
Такая задачка стоит — есть таблица devices, есть таблица device_log. При изменении devices триггерами пишется событие в лог.
Сейчас задача усложняется — редактирование значений вешаем частично на web-морду с разделением прав. При этом надо знать — кто выполнил то или иное действие. Писать новые функции не вижу смысла — в бд триггеры делают свою работу отлично. Хотелось бы передавать параметр $_SESSION['user_id'] в запросы insert/update. Но как?

Comments

[Otkrick]

простите, а проблема в чем? вы же как-то передаёте другие параметры?

Answer 1

[lightsgoout]

stackoverflow.com/a/13172964

Comments

[Владимир Коровин]

О как, да, интересное решение. Спасибо!

Answer 2

[Andrey]

А что вас смущает то? :)

pg_query($conn, "INSERT INTO device_log (user_id) VALUES ({$_SESSION['user_id']})");

Comments

[Владимир Коровин]

Вы повторяете то, что уже триггером описано. В логе несколько полей — type, message, mac, sn, old_val, new_val (и другие). Сейчас вот и uid добавил.
Так вот, я и говорю, в лог пишут триггеры. Событий МНОГО: изменение расположения устройства, включение-выключение портов, изменение в конфиге, отправка на склад, в ремонт, возврат, перенос между филиалами и т.д. и т.п.
Все события срабатывают через объект класса device. Но Вы сейчас предлагаете повторить код триггеров еще и здесь. Этого нужно избежать. Есть триггеры и всё. Намного проще (даже с учетом на будущее расширение системы) добавить в запросы параметр user_id.

[Владимир Коровин]

+ в Вашем случае опять же будет двойная запись в лог. Сначала средствами php с user_id, потом триггером тоже самое, но без user_id.

[Andrey]

А как сейчас остальные значения передаются триггеру? Те, которые old_val, new_val, etc

[Владимир Коровин]

Триггерные функции. Триггеры. plpgsql. NEW.field и OLD.field

Answer 3

[Владимир Коровин]

Промахнулся

Answer 4

[simbajoe]

Можете добавить в devices поле, типа modified_by, в котором хранить последнего пользователя, который менял запись. Тогда в триггере пользователь также будет доступен, и можно будет добавить его в лог.

Comments

[Владимир Коровин]

Администратор БД полностью против этого — далеко не все устройства в этой таблице редактируемы, и в половине случаев поле не нужно. Было временное решение — в поле devices.users вносили нужное значение, а триггер анализировал новое значение на определенные условия и выполнял те или иные действия.

[simbajoe]

У триггера, получается, есть доступ только к изменяемой записи. Если задача сохранять пользователя именно триггером, то эта запись для него является основным источником информации. Можно сделать поле nullable.

Можно создавать отдельного пользователя БД для каждого пользователя веб-морды. Тогда информация о нем будет доступна в триггере. Но создавать столько пользователей не всегда уместно, особенно если их много.

Другой вариант, создать хранимки для вставки и изменения записей, а триггер удалить. Тогда можно что угодно туда передавать.

Answer 5

[mayorovp]

Можно добавить в таблицу вычисляемое поле, которое всегда NULL, а при вставке записей указывать ему значение. Для INSTEAD OF-триггеров должно, по-идее, работать (по крайней мере, в MsSQL работает).