приложения на уровень базы. Чтобы в самом приложении вообще были запросы delete from my_table where id = 1. И чтобы в приложении все выглядело так, как будто действительно произошло удаление (запись пропала).
Для этого делал create rule my_rule as on delete on my_table do instead update my_table set deleted = true where id = old.id.
Причём пол суперюзером всё работает (только данные все видны). А под юзером с forced rls - ошибка.
Вроде ж как логика хранения данных - это уровень бд. Или я тут что-то не то намешал?
Это делается с просьбы разраба или он про это все даже не знает?
Я и есть тот разраб 😂
По сути в приложении уже реализована логика soft delete для этой таблицы. Хотелось избавиться от необходимости «фильтрации» удаленных записей в каждом запросе. При этом через view не вариант
1. вам надо изменять поведение delete, чтобы записи оставались в таблице, как минимум, триггер вешать, 2. вы ещё и хотите, чтобы строки удалялись, но при этом таки оставались в таблице? 3. и вы ещё вешаете дополнительную функциональность (RLS) на таблицу. Вы считаете такие "решения" нормальными? Подобные задачи решаются (мягкое удаление записей) решаются добавлением булевского столбца isalive, и построением рабочих индексов с условием where isalive - true.
Честно говоря, пока тестировал всё это под суперюзером - казалось, что вполне нормально. Можете объяснить, почему это плохо? (Ну кроме того, что оно по итогу не заработало). И в конце вы говорите про partial indexes, да?
> оно по итогу не заработало Вам мало? А вот решение, которое я озвучил - рабочее, проверено временем неоднократно.
Обсуждают сегодня