How do we create a trigger in MySql to disallow deletion of more than 2 rows from (say) employee
table by a single query?
delimiter \\
create trigger not_more_than_2_rows
before delete on employee
begin
declare count int default 0;
if (count>1) then
signal sqlstate '12345'
set message_text = 'cannot delete more than 2 rows at a time'
end if;
set count = count+1
end \\
delimiter ;
but this does not seem to work, the count
variable is getting initialized for each row.
I could see that one way to overcome this is to initialize variable count
once per trigger execution instead of once for each row….
Any other solutions?
Best Answer
This goes against all that righteous and good in triggers but here we go...
Create a table that keep a count of attempted deletes per connection
or to reduce disk I/O make it a MEMORY table
Now get the count from that table and check it
After your issue a DELETE command, you will have to remember to clear the count like this:
or you count clear it before:
Give it a Try !!!
POTENTIAL DRAWBACKS
Here are the pitfalls of doing this:
Pitfall #1
Using an arbitration method like this (via a MyISAM table) will cause a major bottleneck because a
MyISAM
performs a full table lock on eachINSERT
. Using a MEMORY table will not fare much better because although there is far less table access on disk, there is still nominal disk I/O hitting the MEMORY table's.frm
file that can cause a slight bottleneck when given enough database traffic.You cannot make
trigger_happy_employee_deletes
InnoDB because triggers do not work intelligently with InnoDB:Jun 21, 2011
: Using MySQL triggers or transactions?Mar 21, 2011
: Dynamic SQL in MySQL stored routinesPitfall #2
From a coding perspective, you will have to remember to setup this mechanism across your code. If you forget to do this in all necessary places, you will have undesired deletions.
Pitfall #3
If you want this same mechanism for another table, you would either make another
trigger_happy
table for deletes or be tempted to merge all delete triggers into a commontrigger_happy
table, which would make maintenance a total nightmare, not to mention increased bottlenecks by an order of magnitude. Even worse, you may be tempted to merge update and insert triggers into the commontrigger_happy
table.Pitfall #4
The trigger would have to communicate with another table outside the triggered table. That's more internal read traffic just to maintain a count.