SQLite Trigger Kullanımı: CREATE TRIGGER, OLD/NEW

SQLite Trigger Otomatik Olarak SQL Çalıştırır

SQLite trigger, belirli bir tabloda belirli bir olay gerçekleştiğinde otomatik olarak tetiklenen, kayıtlı bir SQL bloğudur. Bir kere yazarsınız, "ne zaman çalışacağını" SQLite senin yerine takip eder.

Genel yapı şöyle:

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    price REAL NOT NULL
);

CREATE TABLE price_history (
    product_id INTEGER,
    old_price REAL,
    new_price REAL,
    changed_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER log_price_change
AFTER UPDATE OF price ON products
BEGIN
    INSERT INTO price_history(product_id, old_price, new_price)
    VALUES (OLD.id, OLD.price, NEW.price);
END;

INSERT INTO products(name, price) VALUES ('Defter', 5.00);
UPDATE products SET price = 6.50 WHERE name = 'Defter';
SELECT * FROM price_history;

Burada price_history tablosuna elle bir INSERT yazmadık. İşi tetikleyici hallediyor. Bundan sonra fiyat ne zaman güncellense — ister CLI'dan, ister bir script'ten, ister bir uygulamadan gelsin — kayıt aynı şekilde tutulacak.

CREATE TRIGGER söz diziminin anatomisi

Sözdizimini parça parça inceleyelim:

CREATE TRIGGER trigger_name
{ BEFORE | AFTER | INSTEAD OF } { INSERT | UPDATE [ OF column_list ] | DELETE }
ON table_name
[ FOR EACH ROW ]
[ WHEN condition ]
BEGIN
    -- bir veya daha fazla ifade
END;

• Zamanlama — BEFORE değişiklikten önce, AFTER sonra çalışır; INSTEAD OF ise işlemin yerine geçer (yalnızca view'larda).
• Olay — tetikleyiciyi hangi işlem çalıştırır. UPDATE OF col1, col2 yazarsanız tetikleyici sadece belirtilen sütunlardaki güncellemelerde devreye girer.
• Tablo — izlenen tablo.
• FOR EACH ROW — SQLite yalnızca satır bazlı tetikleyicileri desteklediği için bu zaten varsayılandır. Okunaklılık için yazabilirsiniz, davranışı değiştirmez.
• WHEN — opsiyonel bir koşul. Gövde yalnızca bu koşul doğruysa çalışır.
• Gövde — BEGIN ile END arasına yazılan bir veya daha fazla ifade. Her ifadenin sonunda noktalı virgül olmalı.

Söz dizimi bundan ibaret. Pratikte gördüğünüz tetikleyicilerin çoğu beş ila on satır arasındadır.

OLD ve NEW: Değişen satıra erişim

Gövdenin içinde, veriye erişmenizi sağlayan iki sözde satır vardır:

• NEW — gelen satır. INSERT ve UPDATE tetikleyicilerinde kullanılabilir.
• OLD — mevcut satır. UPDATE ve DELETE tetikleyicilerinde kullanılabilir.

DELETE tetikleyicisinde yalnızca OLD, INSERT tetikleyicisinde yalnızca NEW bulunur. UPDATE tetikleyicisinde ise her ikisi de mevcuttur.

CREATE TABLE accounts (
    id INTEGER PRIMARY KEY,
    name TEXT,
    balance REAL NOT NULL
);

CREATE TABLE deletions (
    table_name TEXT,
    row_id INTEGER,
    snapshot TEXT,
    deleted_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER archive_account
AFTER DELETE ON accounts
BEGIN
    INSERT INTO deletions(table_name, row_id, snapshot)
    VALUES ('accounts', OLD.id, OLD.name || ' / ' || OLD.balance);
END;

INSERT INTO accounts(name, balance) VALUES ('Rosa', 120.00);
DELETE FROM accounts WHERE name = 'Rosa';
SELECT * FROM deletions;

Silinen satır artık accounts tablosunda yok, ama kaybolmadan önce verisi deletions tablosuna düşmüş bile.

BEFORE: Satırı Doğrula veya Düzelt

BEFORE trigger'ları, satır değişikliği diske yazılmadan önce çalışır. Hata fırlatmak ya da veriyi normalleştirmek için biçilmiş kaftandır:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL,
    created_at TEXT
);

CREATE TRIGGER lowercase_email
BEFORE INSERT ON users
BEGIN
    UPDATE users SET email = email; -- noop, sadece bağlamı göstermek için
END;

CREATE TRIGGER reject_empty_email
BEFORE INSERT ON users
WHEN NEW.email IS NULL OR trim(NEW.email) = ''
BEGIN
    SELECT RAISE(ABORT, 'e-posta boş olamaz');
END;

INSERT INTO users(email) VALUES ('ada@example.com');
INSERT INTO users(email) VALUES ('');
SELECT * FROM users;

İkinci INSERT, tek bir satır bile yazılmadan iptal ediliyor. RAISE(ABORT, '...') çağrısı o anki ifadeyi iptal edip başlangıcına geri sarar. Daha ince ayar lazımsa RAISE(FAIL, ...), RAISE(ROLLBACK, ...) ve RAISE(IGNORE) seçenekleri elinizin altında.

Sadece veri doğrulaması yapacaksanız CHECK kısıtlarını tercih edin — bildirimseldirler ve optimize edici onları tanır. BEFORE trigger'ına ise kuralın başka tablolara bakması ya da CHECK'in ifade edemeyeceği bir iş yapması gerektiğinde başvurun.

WHEN: Koşullu sqlite Trigger'ları

WHEN koşulu, hangi satır değişikliklerinin trigger gövdesini gerçekten tetikleyeceğini filtreler. Her satır için, OLD ve NEW bağlandıktan sonra değerlendirilir:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    total REAL NOT NULL,
    status TEXT NOT NULL
);

CREATE TABLE big_orders (
    order_id INTEGER,
    total REAL,
    flagged_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER flag_big_order
AFTER INSERT ON orders
WHEN NEW.total >= 1000
BEGIN
    INSERT INTO big_orders(order_id, total) VALUES (NEW.id, NEW.total);
END;

INSERT INTO orders(total, status) VALUES (50, 'paid');
INSERT INTO orders(total, status) VALUES (1500, 'paid');
INSERT INTO orders(total, status) VALUES (2200, 'paid');
SELECT * FROM big_orders;

İlk sipariş eşiği geçmiyor. Diğer ikisi geçiyor. WHEN koşulu olmasaydı her ekleme big_orders tablosuna da yazılır, filtrelemeyi okuma tarafında yapmak zorunda kalırdınız.

INSTEAD OF: View'i Yazılabilir Hale Getirme

View'ler varsayılan olarak salt okunurdur. INSTEAD OF trigger'ı, view üzerinde yapılan bir yazma işlemini yakalar ve onun yerine sizin yazdığınız SQL'i çalıştırır — genelde bu işlemi alttaki tablolara yapılan yazmalara çevirir:

CREATE TABLE employees (
    id INTEGER PRIMARY KEY,
    first_name TEXT,
    last_name TEXT,
    salary REAL
);

CREATE VIEW employee_summary AS
SELECT id, first_name || ' ' || last_name AS full_name, salary
FROM employees;

CREATE TRIGGER employee_summary_insert
INSTEAD OF INSERT ON employee_summary
BEGIN
    INSERT INTO employees(first_name, last_name, salary)
    VALUES (
        substr(NEW.full_name, 1, instr(NEW.full_name, ' ') - 1),
        substr(NEW.full_name, instr(NEW.full_name, ' ') + 1),
        NEW.salary
    );
END;

INSERT INTO employee_summary(full_name, salary) VALUES ('Boris Petrov', 60000);
SELECT * FROM employees;

Uygulama, view ile sanki normal bir tabloymuş gibi konuşur. Arka planda first_name ve last_name ayrımını ise trigger halleder.

Trigger'ları Listeleme ve Silme (sqlite drop trigger)

Trigger'lar; tablolar ve indeksler gibi sqlite_master tablosunda tutulur:

CREATE TABLE notes (id INTEGER PRIMARY KEY, body TEXT);

CREATE TRIGGER touch_note
AFTER UPDATE ON notes
BEGIN
    SELECT 1; -- yer tutucu gövde
END;

SELECT name, tbl_name, sql
FROM sqlite_master
WHERE type = 'trigger';

DROP TRIGGER IF EXISTS touch_note;

SELECT count(*) AS remaining
FROM sqlite_master
WHERE type = 'trigger';

DROP TRIGGER IF EXISTS name; güvenli kullanım şeklidir. Trigger'ın bağlı olduğu tabloyu sildiğinizde trigger da otomatik olarak silinir; önceden temizlik yapmanıza gerek yoktur.

Bilmekte Fayda Var: Sık Düşülen Tuzaklar

İlk kez trigger yazanları zorlayan birkaç nokta var:

• Trigger'lar her satır için ayrı ayrı çalışır, ifade başına değil. 1.000 satırı etkileyen bir UPDATE, trigger'ı 1.000 kez tetikler. Trigger gövdesi ağır iş yapıyorsa bu hızla birikir.
• Trigger'lar içinde bulundukları transaction kapsamında çalışır. Dıştaki ifade rollback olursa trigger'ın yazdıkları da geri alınır. Çoğu zaman istediğiniz davranış budur ama "ne olursa olsun bunu logla" amacıyla trigger kullanamayacağınız anlamına da gelir.
• Özyinelemeli (recursive) trigger'lar varsayılan olarak kapalıdır. Aynı tabloyu değiştiren bir trigger, PRAGMA recursive_triggers = ON; ayarı yapılmadıkça kendini yeniden tetiklemez. Belirli bir gerekçeniz yoksa kapalı bırakın.
• Uygulama tarafındaki yazımlar trigger'ları atlayabilir, ama bu ancak veritabanını es geçtiğinizde olur. Tüm yazma işlemleri SQLite üzerinden geçtiği sürece trigger çalışır. Ham SQL ile toplu işlem yapan ORM'ler bile trigger'ları tetikler.
• İş mantığını birçok trigger'a dağıtmayın. Çağrı noktasından görünmezler — "bu satır nereden geldi?" diye debug eden biri sqlite_master içinde grep yapmak zorunda kalır. Trigger'ları kesişen sorumluluklar için kullanın (audit log, türetilmiş kolonlar, view'a yazılabilirlik kazandırma); gerisini uygulama kodunda tutun.

Gerçekçi Bir Audit-Log Örneği

Şimdi tüm bu kalıpları birleştirelim — posts tablosundaki her değişikliği takip edelim:

CREATE TABLE posts (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    body TEXT,
    updated_at TEXT
);

CREATE TABLE post_audit (
    post_id INTEGER,
    action TEXT,
    old_title TEXT,
    new_title TEXT,
    at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER posts_audit_update
AFTER UPDATE OF title, body ON posts
BEGIN
    UPDATE posts SET updated_at = CURRENT_TIMESTAMP WHERE id = NEW.id;
    INSERT INTO post_audit(post_id, action, old_title, new_title)
    VALUES (NEW.id, 'update', OLD.title, NEW.title);
END;

INSERT INTO posts(title, body) VALUES ('Taslak', 'ilk hâli');
UPDATE posts SET title = 'Yayımlandı' WHERE id = 1;
SELECT id, title, updated_at FROM posts;
SELECT * FROM post_audit;

Tek bir trigger, hem updated_at alanını güncel tutar hem de tek bir noktadan denetim (audit) kaydı yazar. UPDATE sorgusunu çalıştıran uygulama kodunun bu işlerden haberi bile olmaz.

Sıradaki Konu: JSON Desteği

Trigger'lar, satır seviyesindeki olayların otomasyonunu üstlenir. SQLite'ın bir sonraki ileri seviye konusu ise satırın içine ne koyabileceğinizle ilgili: JSON. SQLite, yapılandırılmış veriyi sorgulamak ve güncellemek için SQL'den çıkmadan kullanabileceğiniz eksiksiz bir JSON fonksiyon seti sunuyor — bir sonraki sayfada tam olarak buna bakacağız.