Prevent record insert without mutating-CodePudding

I am trying to prevent inserts of records into a table for scheduling. If the start date of the class is between the start and end date of a previous record, and that record is the same location as the new record, then it should not be allowed.

I wrote the following trigger, which compiles, but of course mutates, and therefore has issues. I looked into compound triggers to handle this, but either it can't be done, or my understanding is bad, because I couldn't get that to work either. I would have assumed for a compound trigger that I'd want to do these things on before statement, but I only got errors.

I also considered after insert/update, but doesn't that apply after it's already inserted? It feels like that wouldn't be right...plus, same issue with mutation I believe.

The trigger I wrote is:

CREATE OR REPLACE TRIGGER PREVENT_INSERTS 
before insert or update on tbl_classes

    DECLARE
        v_count number;
        v_start TBL_CLASS_SCHED.start_date%type;
        v_end TBL_CLASS_SCHED.end_date%type;
        v_half TBL_CLASS_SCHED.day_is_half%type;
    BEGIN
        select start_date, end_date, day_is_half
        into v_start, v_end, v_half
        from tbl_classes 
        where class_id = :NEW.CLASS_ID
        and location_id = :NEW.location_id;

        select count(*) 
        into v_count 
        from TBL_CLASS_SCHED
        where :NEW.START_DATE >= (select start_date 
                                   from TBL_CLASS_SCHED 
                                   where class_id = :NEW.CLASS_ID
                                   and location_id = :NEW.location_id)
        and :NEW.START_DATE <= (select end_date
                                   from TBL_CLASS_SCHED
                                   where class_id = :NEW.CLASS_ID
                                   and location_id = :NEW.location_id);

        if (v_count = 2) THEN
            RAISE_APPLICATION_ERROR(-20001,'You cannot schedule more than 2 classes that are a half day at the same location');
        end if;
        if (v_count = 1 and :NEW.day_is_half = 1) THEN
            if (v_half != 1) THEN
                RAISE_APPLICATION_ERROR(-20001,'You cannot schedule a class during another class''s time period of the same type at the same location');
            end if;
        end if;
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            null;
    END;
    
end PREVENT_INSERTS ;

Perhaps it can't be done with a trigger, and I need to do it multiple ways? For now I've done it using the same logic before doing an insert or update directly, but I'd like to put it as a constraint/trigger so that it will always apply (and so I can learn about it).

CodePudding user response：

There are two things you'll need to fix.

Mutating occurs because you are trying to do a SELECT in the row level part of a trigger. Check out COMPOUND triggers as a way to mitigate this. Basically you capture info at row level, and the process that info at the after statement level. Some examples of that in my video here https://youtu.be/EFj0wTfiJTw
Even with the mutating issue resolved, there is a fundamental flaw in the logic here (trigger or otherwise) due to concurrency. All you need is (say) three or four people all using this code at the same time. All of them will get "Yes, your count checks are ok" because none of them can see each others uncommitted data. Thus they all get told they can proceed and when they finally commit, you'll have multiple rows stored hence breaking the rule your tirgger (or wherever your code is run) was trying to enforce. You'll need to look an appropriate row so that you can controlling concurrent access to the table. For an UPDATE, that is easy because this means there is already some row(s) for the location/class pairing. For an INSERT, you'll need to ensure an appropriate unique constraint is in place on a parent table somewhere. Hard to say without seeing the entire model

CodePudding user response：

In principle a compound trigger could be this one:

CREATE OR REPLACE TYPE CLASS_REC AS OBJECT(
    CLASS_ID INTEGER, 
    LOCATION_ID INTEGER,
    START_DATE DATE,
    END_DATE DATE,
    DAY_IS_HALF INTEGER
);

CREATE OR REPLACE TYPE CLASS_TYPE AS TABLE OF CLASS_REC;


CREATE OR REPLACE TRIGGER UIC_CLASSES 
    FOR INSERT OR UPDATE ON TBL_CLASSES
COMPOUND TRIGGER

    classes CLASS_TYPE;
    v_count NUMBER;
    v_half TBL_CLASS_SCHED.DAY_IS_HALF%TYPE;

BEFORE STATEMENT IS 
BEGIN
    classes := CLASS_TYPE();    
END BEFORE STATEMENT;   

BEFORE EACH ROW IS   
BEGIN       
    classes.EXTEND;
    classes(classes.LAST) := CLASS_REC(:NEW.CLASS_ID, :NEW.LOCATION_ID, :NEW.START_DATE, :NEW.END_DATE, :NEW.DAY_IS_HALF);
END BEFORE EACH ROW;


AFTER STATEMENT IS 
BEGIN
    
    FOR i IN classes.FIRST..classes.LAST LOOP
        SELECT COUNT(*), v_half 
        INTO v_count, v_half
        FROM TBL_CLASSES
        WHERE CLASS_ID = classes(i).CLASS_ID
            AND LOCATION_ID = classes(i).LOCATION_ID
            AND classes(i).START_DATE BETWEEN START_DATE AND END_DATE
        GROUP BY v_half;

        IF v_count = 2 THEN
            RAISE_APPLICATION_ERROR(-20001,'You cannot schedule more than 2 classes that are a half day at the same location');
        END IF;
        IF v_count = 1 AND classes(i).DAY_IS_HALF = 1 THEN
            IF v_half != 1 THEN
                RAISE_APPLICATION_ERROR(-20001,'You cannot schedule a class during another class''s time period of the same type at the same location');
            end if;
        end if; 
    END LOOP;

END AFTER STATEMENT;    


END;
/

But as stated by @Connor McDonald, there are several design flaws - even in a single user environment.

A user may update the DAY_IS_HALF, I don't think the procedure covers all variants. Or a user updates END_DATE and by that, the new time intersects with existing classes.

CodePudding user response：

Better avoid direct insert into the table and create a PL/SQL stored procedure in which you perform all the validations you need and then, if none of the validations fail, perform the insert. And grant execute on that procedure to the applications and do not grant applications insert on that table. That is a way to have all the data-related business rules in the database and make sure that no data that violates those rules in entered into the tables, no matter by what client application, for any client application will call a stored procedure to perform insert or update and will not perform DML directly on the table.

CodePudding user response：

I think the main problem is the ambiguity of the role of the table TBL_CLASS_SCHED and the lack of clear definition of the DAY_IS_HALF column (morning, afternoon ?). If the objective is to avoid 2 reservations of the same location at the same half day, the easiest solution is to use TBL_CLASS_SCHED to enforce the constraint with (start_date, location_id) being the primary key, morning reservation having start_date truncated at 00:00 and afternoon reservation having start_date set at 12:00, and you don't need end_date in that table, since each row represents an half day reservation. The complete solution will then need a BEFORE trigger on TBL_CLASSES for UPDATE and INSERT events to make sure start_date and end_date being clipped to match the 00:00 and 12:00 rule and an AFTER trigger on INSERT, UPDATE and DELETE where you will calculate all the half-day rows to maintain in TBL_CLASS_SCHED. (So 1 full day reservation in TBL_CLASSES, will generate 2 rows in TBL_CLASS_SCHED). Since you maintain TBL_CLASS_SCHED from triggers set on TBL_CLASSES without any need to SELECT on the later, you don't have to worry about mutating problem, and because you will constraint start_date to be either at 00:00 or 12:00, the primary key constraint will do the job for you. You may even add a unique index on (start_date, classe_id) in TBL_CLASS_SCHED to avoid a classe to be scheduled at 2 locations at the same time, if you need to.