محفزات SQLite: CREATE TRIGGER و BEFORE/AFTER و OLD/NEW

محفزات sqlite: تنفيذ SQL تلقائيًا

المحفّز (Trigger) عبارة عن كتلة SQL مخزّنة داخل قاعدة البيانات، تعمل تلقائيًا عند وقوع حدث معيّن على جدول محدّد. تكتبه مرّة واحدة، ويتكفّل SQLite بعدها بأمر "متى يُنفَّذ".

الصيغة العامة:

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 ('دفتر', 5.00);
UPDATE products SET price = 6.50 WHERE name = 'دفتر';
SELECT * FROM price_history;

لم نكتب أمر INSERT صريحًا في جدول price_history، بل المحفّز هو من تكفّل بذلك. وكل تحديث لاحق للسعر سيُسجَّل بنفس الطريقة، سواء جاء من سطر الأوامر أو من سكربت أو من تطبيق.

تشريح جملة CREATE TRIGGER في sqlite

لنقرأ صيغة إنشاء المحفّز جزءًا جزءًا:

CREATE TRIGGER trigger_name
{ BEFORE | AFTER | INSTEAD OF } { INSERT | UPDATE [ OF column_list ] | DELETE }
ON table_name
[ FOR EACH ROW ]
[ WHEN condition ]
BEGIN
    -- جملة واحدة أو أكثر
END;

• التوقيت (Timing) — BEFORE يُنفَّذ قبل التغيير، وAFTER يُنفَّذ بعده، أما INSTEAD OF فيحلّ محلّ العملية (ويعمل مع العروض views فقط).
• الحدث (Event) — العملية التي تُطلِق المحفّز. الصيغة UPDATE OF col1, col2 تُقصِر التشغيل على تعديلات أعمدة بعينها.
• الجدول — الجدول الذي تراقبه.
• FOR EACH ROW — SQLite لا يدعم سوى المحفّزات على مستوى الصف، لذا هذه العبارة ضمنية. يمكنك كتابتها للتوضيح فقط دون أي أثر فعلي.
• WHEN — شرط اختياري، فلا يُنفَّذ جسم المحفّز إلا إذا تحقّق.
• الجسم (Body) — جملة أو أكثر بين BEGIN وEND، وكل جملة يجب أن تنتهي بفاصلة منقوطة.

هذه هي القواعد كاملة. أغلب محفّزات sqlite في الواقع لا تتجاوز خمسة إلى عشرة أسطر.

OLD و NEW في محفزات sqlite: الصف الذي يتغيّر

داخل جسم المحفّز، يوفّر لك SQLite صفّين وهميّين للوصول إلى البيانات:

• NEW — الصف الجديد القادم. متاح في محفّزات INSERT وUPDATE.
• OLD — الصف الموجود حاليًا. متاح في محفّزات UPDATE وDELETE.

محفّز DELETE يملك OLD فقط، ومحفّز INSERT يملك NEW فقط، أما محفّز UPDATE فيملك الاثنين معًا.

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 ('روزا', 120.00);
DELETE FROM accounts WHERE name = 'روزا';
SELECT * FROM deletions;

الصف المحذوف اختفى من accounts، لكن بياناته انحفظت في deletions قبل ما يروح.

محفز BEFORE في sqlite: التحقق من الصف أو تعديله

محفزات BEFORE تشتغل قبل ما يتم تطبيق التغيير على القرص فعليًا، وهي مفيدة لرفع خطأ أو لتطبيع البيانات قبل تخزينها:

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; -- لا تفعل شيئًا، مجرد توضيح للسياق
END;

CREATE TRIGGER reject_empty_email
BEFORE INSERT ON users
WHEN NEW.email IS NULL OR trim(NEW.email) = ''
BEGIN
    SELECT RAISE(ABORT, 'لا يمكن أن يكون البريد الإلكتروني فارغًا');
END;

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

عملية INSERT الثانية تتوقف قبل أن تُكتب أي صفّ. الاستدعاء RAISE(ABORT, '...') يُلغي العبارة الحالية ويتراجع إلى ما قبلها مباشرة، أمّا RAISE(FAIL, ...) وRAISE(ROLLBACK, ...) وRAISE(IGNORE) فتمنحك تحكّمًا أدقّ بما يحدث بعد ذلك.

إذا كان هدفك مجرّد التحقّق من صحّة البيانات، فالأفضل الاعتماد على قيود CHECK؛ فهي تصريحية ويأخذها المُحسِّن (optimizer) في الحسبان. أمّا محفّز BEFORE فاستخدمه حين تحتاج القاعدة إلى مراجعة جداول أخرى أو إلى منطق لا يستطيع CHECK التعبير عنه.

شرط WHEN في trigger sqlite: المحفّزات المشروطة

تعمل عبارة WHEN كمُرشِّح يُحدّد أيّ تغييرات على الصفوف ستُشغّل جسم المحفّز فعلًا. يُقيَّم هذا الشرط لكلّ صفّ على حدة، بعد ربط OLD وNEW:

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;

الطلب الأول لا يجتاز الشرط، أما الطلبان الآخران فيجتازانه. لو لم نضع جملة WHEN، لكانت كل عملية إدراج ستُكتب في جدول big_orders، وكنت ستضطر للتصفية عند القراءة بدلاً من ذلك.

محفز INSTEAD OF: جعل العرض قابلاً للكتابة

الـ Views في SQLite للقراءة فقط افتراضياً. محفز INSTEAD OF يعترض أي عملية كتابة على الـ view ويُنفّذ بدلاً منها كود SQL الخاص بك، وعادةً ما يُترجم ذلك إلى عمليات كتابة على الجداول الأصلية:

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;

التطبيق يتعامل مع العرض (View) وكأنه جدول عادي، أما المحفّز فيتكفّل بتقسيم الاسم إلى first_name و last_name خلف الكواليس دون أن يشعر بذلك أحد.

عرض محفزات قاعدة البيانات وحذفها في sqlite

تُخزَّن المحفزات في الجدول sqlite_master جنباً إلى جنب مع الجداول والفهارس:

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

CREATE TRIGGER touch_note
AFTER UPDATE ON notes
BEGIN
    SELECT 1; -- نص نائب
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; هي الصيغة الآمنة. وعند حذف جدول يحتوي على محفز، يُحذف المحفز تلقائياً معه — لا داعي لتنظيف أي شيء مسبقاً.

أخطاء شائعة يقع فيها المبتدئون

هناك بعض النقاط التي تُربك المطورين أول مرة:

• المحفز يعمل لكل صف، لا لكل عبارة. عبارة UPDATE تُعدّل 1000 صف تُشغّل المحفز 1000 مرة. وإذا كان جسم المحفز ثقيلاً، فالحساب يتراكم بسرعة.
• المحفزات تعمل ضمن المعاملة المحيطة بها. إذا تراجعت العبارة الخارجية (rollback)، تتراجع كتابات المحفز أيضاً. هذا عادةً هو السلوك المطلوب، لكنه يعني أن المحفز ليس حلاً لـ"سجّل هذا مهما حدث".
• المحفزات التكرارية معطّلة افتراضياً. المحفز الذي يُعدّل نفس الجدول لن يُعيد تشغيل نفسه ما لم تُفعّل PRAGMA recursive_triggers = ON;. اتركها معطّلة إلا إذا كان لديك سبب محدد.
• يمكن للتطبيق تجاوز المحفزات، لكن فقط بتجاوز قاعدة البيانات نفسها. ما دامت كل عمليات الكتابة تمر عبر SQLite، فالمحفز سيعمل. حتى أُطر الـ ORM التي ترسل دفعات SQL خام تُشغّل المحفزات.
• لا تُوزّع منطق الأعمال على محفزات كثيرة. فهي غير مرئية من موضع الاستدعاء — من يحاول تتبع "من أين جاء هذا الصف؟" سيضطر للبحث في sqlite_master. استخدمها للأغراض العرضية المشتركة (سجلات التدقيق، الأعمدة المشتقة، جعل الـ views قابلة للكتابة)، واترك الباقي في كود التطبيق.

مثال واقعي: سجل تدقيق (Audit Log)

لنجمع ما سبق في مثال عملي — نتتبّع كل تغيير يحدث على جدول posts:

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 ('مسودة', 'النسخة الأولى');
UPDATE posts SET title = 'منشور' WHERE id = 1;
SELECT id, title, updated_at FROM posts;
SELECT * FROM post_audit;

محفّز واحد يكفي للحفاظ على دقّة updated_at وكتابة سجلّ تدقيق في مكان واحد فقط. الكود التطبيقي الذي ينفّذ UPDATE لا يحتاج أن يعرف بوجود أيٍّ من هذين الأمرين أصلاً.

ما التالي: دعم JSON

تتولّى المحفّزات أتمتة ما يحدث حول صفوف الجدول. أمّا الميزة المتقدّمة التالية في SQLite فهي ما يمكنك تخزينه داخل الصف نفسه — أي JSON. يوفّر SQLite مجموعة كاملة من دوال JSON للاستعلام عن البيانات المهيكلة وتعديلها دون مغادرة بيئة SQL، وهذا موضوع الصفحة التالية.