AFTER trigger — database’dagi INSERT, UPDATE yoki DELETE amali jadval satriga qo‘llanib, tegishli constraintlar muvaffaqiyatli o‘tgandan keyin bajariladigan triggerdir. U audit yozuvi, derived table yangilanishi yoki outbox event yaratish uchun ishlatiladi. Trigger hali ham asosiy transaction ichida ishlaydi.
Yangi holatni kuzatish
AFTER INSERT trigger yozilgan NEW satrni, AFTER DELETE OLD satrni ko‘radi. UPDATE ikkala holatni taqqoslaydi. Generated ID, default va normalization yakunlangan qiymatlar mavjud bo‘lgani uchun audit real saqlangan holatni qayd etadi.
Trigger odatda asosiy rowni o‘zgartirish uchun emas. O‘sha table’ga qayta update yuborish qo‘shimcha trigger invocation, write amplification va recursion keltiradi. Incoming qiymatni o‘zgartirish BEFORE trigger yoki generated column vazifasidir.
Audit yozuvi
Audit trigger actor, vaqt, operation, primary key va o‘zgargan fieldlarni alohida tablega yozishi mumkin. Actor application session contextidan olinadi; umumiy database user ishlatilsa haqiqiy end-user ID alohida xavfsiz contextda uzatiladi.
Audit tablega write asosiy transaction bilan atomik: business update rollback bo‘lsa audit ham rollback qiladi. “Muvaffaqiyatsiz urinish” auditini shu trigger qayd eta olmaydi, chunki statement bajarilmagan; database log yoki application security logi kerak.
Outbox event
AFTER trigger business row bilan bir transactionda outbox tablega event qo‘shishi mumkin. Worker commitdan keyin eventni brokerga yuboradi. Bu database write va message publish orasidagi dual-write bo‘shligini kamaytiradi.
Event payload schema, aggregate ID va transactiondan kelib chiqadigan versionni saqlaydi. Trigger har row uchun event yaratsa bulk update minglab event hosil qiladi. Statement-level transition table yoki applicationning explicit batch eventi maqsadga mos bo‘lishi mumkin.
Constraint va cascade
Foreign key cascade boshqa tablelarda triggerlarni chaqirishi mumkin. Ordering enginega bog‘liq va bir statementning barcha side effectlari transaction ichida qoladi. Trigger parent o‘chirilganda child allaqachon o‘chganmi yoki hali mavjudmi degan taxminni hujjatga tayanmasdan qilish xavfli.
Deferred constraint commitgacha tekshirilmasa AFTER trigger vaqtida yakuniy integrity hali tasdiqlanmagan bo‘lishi mumkin. Trigger chiqargan derived data ham transaction rollback bilan bekor qilinadi.
Row va statement darajasi
Row-level AFTER trigger ta’sirlangan har satr uchun chaqiriladi. Statement-level trigger bir marta ishlaydi va ayrim tizimlarda old/new transition table orqali barcha satrni ko‘radi. Katta bulk operatsiyada statement darajasi samaraliroq bo‘lishi mumkin.
Row trigger tartibni kafolatlamasligi mumkin. Event ketma-ketligi kerak bo‘lsa primary key yoki explicit sequence ishlatiladi. Physical row processing orderga tayanilmaydi.
Performance va lock
AFTER trigger client javobidan oldin tugaydi. Og‘ir aggregation yoki remote chaqiruv transaction locklarini uzoq saqlaydi. Derived summaryni incremental update qilish ham hot counter rowda contention yaratishi mumkin.
Asinxron workerga faqat durable outbox yozuvi qoldirish transactionni qisqa tutadi. Worker retry va idempotency bilan tashqi side effectni boshqaradi. Trigger ichidan bevosita email yoki HTTP yuborish rollback bilan tashqi amalni qaytarib bo‘lmas nomoslik yaratadi.
Maintenance
Trigger schema migration bilan versionlanadi. Column rename payload va audit functionni buzishi mumkin. Disabled trigger bilan bulk load bajarilsa keyingi backfill derived holatni tiklashi kerak; “vaqtincha” o‘chirish hujjatsiz qolmaydi.
Test transaction commit, rollback, bulk operation va cascade holatlarini qamrab oladi. Triggerning mavjudligi application repositorydan tashqarida yashirin qolmasligi uchun schema introspection va migration review ishlatiladi.
Bog‘liq tushunchalar
Database trigger, BEFORE trigger, Audit log, Outbox pattern, Row-level trigger, Statement-level trigger, Transaction