Locking a venue the moment an event is approved

The most-clashed resource on any campus is the hall. Two fests want the same auditorium on the same evening, and whoever emails the venue in-charge last loses.

We wanted concurrent requests to coexist freely — and a single winner to be picked the instant an event is actually approved, with no race.

Requests coexist, approvals are exclusive

A reservation mirrors its parent event's approval state. While an event moves through the unit, module, and IQAC chain, its reservation sits in requested. Many requested rows can overlap on the same slot — that is fine, nobody owns it yet.

The database enforces the rule that matters: a partial exclusion constraint allows only one approved reservation per slot. Overlapping requested rows are unconstrained; overlapping approved rows are impossible.

The finalize transaction

When IQAC approval flips an event to final, one transaction does three things:

1. promotes the target reservation to approved,
2. cascades sibling overlapping requested rows to declined, and
3. records a reason on each: venue assigned to another event.

If two finalizations race for the same slot, the exclusion constraint rejects the second with a conflict — the loser never sees a half-booked state.

What organizers see

The calendar shows three states: green for free, amber for "N events have requested this", red for approved. Declined organizers get an email and an in-app notice with a direct link to re-pick a slot — so a lost venue is a two-minute fix, not a dead end.