BEFORE trigger — database’da INSERT, UPDATE yoki DELETE amali asosiy jadvalga qo‘llanishidan oldin ishga tushadigan triggerdir. U kelayotgan qiymatni tekshirish, normallashtirish yoki row yozilishidan avval rad etish uchun ishlatiladi. Aniq imkoniyat va NEW hamda OLD semantikasi database tizimiga bog‘liq.
Bajarilish nuqtasi
INSERT uchun NEW yangi satr qiymatlarini, UPDATE uchun OLD avvalgi va NEW yangi holatni ifodalaydi. DELETEda odatda faqat OLD mavjud. BEFORE trigger constraint tekshiruvining ayrim qismlaridan oldin yoki keyin ishlashi engine tartibiga bog‘liq; default, generated column va constraint ordering hujjatdan tekshiriladi.
CREATE TRIGGER normalize_email
BEFORE INSERT OR UPDATE ON users
FOR EACH ROW
EXECUTE FUNCTION normalize_user_email();
Trigger function NEW.emailni normal shaklga keltirib qaytarishi mumkin. Yozuv bir xil rule bilan barcha clientlar uchun bajariladi.
Qiymatni o‘zgartirish
BEFORE row trigger incoming satrni fizik write’dan oldin o‘zgartira oladi. Trim, canonical case yoki derived audit fieldni to‘ldirish odatiy misol. Biroq biznesga muhim transformation yashirin bo‘lsa application yozgan qiymat bilan database saqlagan qiymat farqlanadi.
Generated column yoki explicit application mapping ko‘pincha tushunarliroq. Trigger faqat barcha writerlar uchun markaziy va transaction ichidagi qoida zarur bo‘lganda ishlatiladi. Original qiymat audit uchun kerak bo‘lsa normallashtirish uni yo‘qotmasligi kerak.
Yozuvni rad etish
Trigger exception chiqarib statementni to‘xtatishi mumkin. Cross-row invariant yoki tashqi tablega murakkab lookup bajarilishi ehtimoli bor. Oddiy null, range va referential qoidalar NOT NULL, CHECK, UNIQUE hamda foreign key bilan ifodalangani ma’qul, chunki optimizer va migration vositalari ularni yaxshiroq tushunadi.
Trigger errori barqaror code va xavfsiz message beradi. Secret yoki ichki SQL clientga chiqmaydi. Bulk importda bitta invalid row butun statement transactionini rollback qilishi mumkin.
Rowni tashlab yuborish
Ayrim database BEFORE row trigger maxsus qiymat qaytarib row operationni bekor qilishi mumkin. Bu INSERT statement muvaffaqiyatli ko‘rinsa ham ayrim satr yozilmagan holat yaratadi. Affected row count va application kutishi aniq bo‘lishi kerak.
Silent drop data lossni yashirishi mumkin. Ko‘pincha explicit constraint error yoki staging table’da quarantine afzal. Agar duplicate telemetryni chiqarib tashlash kabi use case bo‘lsa drop counter va audit yuritiladi.
Trigger tartibi va recursion
Bir event uchun bir nechta BEFORE trigger mavjud bo‘lsa ularning ordering qoidasi databasega bog‘liq. Nom, yaratilish tartibi yoki explicit order ishlatilishi mumkin. Triggerlar bir-birining NEW qiymatiga tayanmasligi uchun tartib hujjatlashtiriladi.
Trigger boshqa tablega yozib, u yerdagi triggerni chaqirishi mumkin. Circular recursion transactionni tugatmaydi yoki depth limitga uriladi. Session flag bilan recursionni yashirish connection poolda state sizishiga olib kelishi mumkin; idempotent mantiq va aniq dependency afzal.
Concurrency
BEFORE triggerdagi “mavjudmi” query parallel transaction bilan race qilishi mumkin. Noyoblik unique constraint bilan majburiy qilinadi. Trigger lock olsa lock tartibi deadlock xavfini yaratadi. Bir xil resurslar barcha code pathda bir tartibda olinadi.
Trigger transactionning bir qismi bo‘lgani uchun uning latency’si har write’ga qo‘shiladi. External HTTP chaqiruv transactionni uzoq ochiq ushlab turadi va retry semantikasini buzadi; outbox pattern bunday side effectni commitdan keyingi workerga beradi.
Bog‘liq tushunchalar
Database trigger, AFTER trigger, Row-level trigger, Constraint, NEW row, Transaction, Outbox pattern