نقاط الحفظ في SQLite: SAVEPOINT و ROLLBACK TO

نقطة الحفظ: علامة مرجعية باسم داخل المعاملة

المعاملة العادية في SQLite تعمل بمبدأ "الكل أو لا شيء"؛ فكل ما يقع بين BEGIN و COMMIT إمّا يُحفظ دفعة واحدة وإمّا يُلغى دفعة واحدة. هذا السلوك جيد في معظم الحالات، لكنك أحياناً تحتاج إلى تحكم أدق: "جرّب هذه المجموعة من التغييرات، فإن حدث خطأ تراجع عنها وحدها واترك بقية المعاملة شغّالة".

هنا يأتي دور نقاط الحفظ في SQLite. تضع علامة مرجعية باسم معيّن، تنفّذ ما تريد، ثم إمّا أن تُثبّت العمل عبر RELEASE، أو ترجع إلى تلك العلامة عبر ROLLBACK TO.

CREATE TABLE accounts (name TEXT, balance INTEGER);
INSERT INTO accounts VALUES ('Ada', 100), ('Boris', 100);

BEGIN;
  UPDATE accounts SET balance = balance - 30 WHERE name = 'Ada';

  SAVEPOINT risky;
    UPDATE accounts SET balance = balance + 30 WHERE name = 'Nobody';
  ROLLBACK TO risky;

  UPDATE accounts SET balance = balance + 30 WHERE name = 'Boris';
COMMIT;

SELECT * FROM accounts;

يبقى الخصم من حساب Ada والإضافة لحساب Boris كما هما، أمّا التحديث الخاطئ على Nobody فقد تم التراجع عنه دون أن نخسر باقي المعاملة.

الأوامر الثلاثة

كل ما تحتاجه يتلخّص في ثلاث تعليمات فقط:

• SAVEPOINT name — لوضع علامة مرجعية (نقطة حفظ).
• RELEASE SAVEPOINT name — تثبيت كل ما أُنجز بعد نقطة الحفظ، مع إزالة النقطة نفسها.
• ROLLBACK TO SAVEPOINT name — التراجع عن كل ما حدث بعد نقطة الحفظ، مع إبقاء النقطة قائمة لتتمكّن من المحاولة مجدّدًا.

كلمة SAVEPOINT بعد RELEASE و ROLLBACK TO اختيارية، فبإمكانك كتابة RELEASE risky أو ROLLBACK TO risky ويعملان بنفس الكفاءة.

CREATE TABLE log (msg TEXT);

BEGIN;
  INSERT INTO log VALUES ('بداية');

  SAVEPOINT step1;
    INSERT INTO log VALUES ('تم إنجاز الخطوة 1');
  RELEASE step1;

  SAVEPOINT step2;
    INSERT INTO log VALUES ('محاولة الخطوة 2');
  ROLLBACK TO step2;
    INSERT INTO log VALUES ('إعادة محاولة الخطوة 2');
  RELEASE step2;
COMMIT;

SELECT * FROM log;

صف محاولة الخطوة 2 لم يكن موجودًا أصلًا من وجهة نظر قاعدة البيانات النهائية. أما باقي التغييرات فقد ثُبِّتت كلها.

استخدام SAVEPOINT بدون معاملة خارجية

إليك مفاجأة صغيرة: يمكنك تنفيذ SAVEPOINT دون الحاجة إلى BEGIN قبله. في هذه الحالة، تفتح SQLite معاملةً ضمنية بشكل تلقائي، وتلعب نقطة الحفظ الخارجية دور المعاملة نفسها. عندها يقوم RELEASE على تلك النقطة بتثبيت التغييرات (Commit)، بينما يُرجِع ROLLBACK TO الحالة إلى الوراء دون تثبيت أي شيء.

CREATE TABLE notes (text TEXT);

SAVEPOINT outer;
  INSERT INTO notes VALUES ('مرحبا');
RELEASE outer;

SELECT * FROM notes;

لهذا السبب يُطلق على نقاط الحفظ أحيانًا اسم "المعاملات المُسمّاة". لكن الخلط بين الأسلوبين داخل كود حقيقي يجلب الفوضى — اختر واحدًا والتزم به. الشائع أن يستخدم المطورون BEGIN ... COMMIT صراحةً للحدود الخارجية، ويتركون نقاط الحفظ لنقاط التراجع الجزئي الداخلية فقط.

نقاط حفظ متداخلة في SQLite

نقاط الحفظ في SQLite قابلة للتكديس؛ بمعنى أنه يمكنك إنشاء نقطة حفظ داخل نقطة حفظ أخرى، والتراجع عن الداخلية دون أن تمسّ الخارجية بأي ضرر:

CREATE TABLE items (name TEXT);

BEGIN;
  INSERT INTO items VALUES ('a');

  SAVEPOINT outer;
    INSERT INTO items VALUES ('b');

    SAVEPOINT inner;
      INSERT INTO items VALUES ('c');
    ROLLBACK TO inner;
    -- تم حذف 'c'؛ بينما لا يزال كل من 'a' و'b' موجودًا

    INSERT INTO items VALUES ('d');
  RELEASE outer;
COMMIT;

SELECT * FROM items;

المحتوى النهائي: a، b، d. لاحظ أن التراجع إلى inner أزال c فقط، بينما بقي العمل المنجز قبل inner (أي إدراج b) كما هو، والمعاملة استمرت في عملها دون انقطاع.

كذلك التراجع إلى نقطة حفظ خارجية يلغي كل ما تم على المستويات الداخلية أيضًا، إذ تنهار كامل المكدس فوق ذلك الاسم دفعة واحدة:

CREATE TABLE items (name TEXT);

BEGIN;
  SAVEPOINT outer;
    INSERT INTO items VALUES ('ب');
    SAVEPOINT inner;
      INSERT INTO items VALUES ('ج');
  ROLLBACK TO outer;
COMMIT;

SELECT * FROM items;

كلٌّ من b وc اختفيا. الأمر ROLLBACK TO outer يُرجِع كل ما حدث منذ تعيين outer، بما في ذلك inner وإدراج c.

لماذا نستخدم نقاط الحفظ في SQLite؟

الحالة الكلاسيكية لاستخدام SAVEPOINT هي معالجة دفعة من العناصر، حيث يُسمح بفشل عنصر واحد دون إلغاء الدفعة كاملة. غلِّف كل عنصر بنقطة حفظ، فإن فشل، تراجَع إلى تلك النقطة وتابع مع البقية:

CREATE TABLE imports (id INTEGER PRIMARY KEY, value INTEGER CHECK(value > 0));

BEGIN;
  SAVEPOINT row1;
    INSERT INTO imports(value) VALUES (10);
  RELEASE row1;

  SAVEPOINT row2;
    INSERT INTO imports(value) VALUES (-5);  -- سيفشل قيد CHECK
  ROLLBACK TO row2;

  SAVEPOINT row3;
    INSERT INTO imports(value) VALUES (20);
  RELEASE row3;
COMMIT;

SELECT * FROM imports;

في الكود الحقيقي للتطبيق، عملية الإدراج الخاطئة سترفع استثناءً، فيلتقطه التطبيق ويُنفّذ ROLLBACK TO ثم يكمل عمله. النتيجة: الصفّان السليمان يُحفظان، والصف الخاطئ لا يُفسد الدفعة كلها.

هذا النمط بالذات هو ما تستخدمه أنظمة ORM وأدوات الـ migrations لتنفيذ ما يُسمى بالمعاملات المتداخلة — فهي لا تُداخل كتل BEGIN فعلياً (لأن SQLite لا يسمح بذلك أصلاً)، بل تُحوّل الاستدعاءات المتداخلة إلى نقاط حفظ (SAVEPOINT).

أمور ينبغي الانتباه إليها

هناك تفاصيل صغيرة كثيراً ما يقع فيها المبتدئون مع نقاط الحفظ في SQLite:

• COMMIT يُثبّت المعاملة كاملة دائماً. لا يهم كم عدد نقاط الحفظ المفتوحة لديك — تنفيذ COMMIT (أو مرادفه END) يُغلق المعاملة الخارجية بأكملها. لا تتعامل مع RELEASE على أنه تثبيت جزئي؛ لا شيء يصير دائماً قبل أن تُثبَّت المعاملة المُحيطة.
• ROLLBACK (بدون TO) يُلغي كل شيء. فهو يُنهي المعاملة ويتخلّص من جميع نقاط الحفظ المفتوحة. إذا أردت إبقاء المعاملة حيّة، استعمل ROLLBACK TO name.
• نقطة الحفظ تبقى مفتوحة حتى تُحرَّر أو يُتراجَع عبرها. نسيان RELEASE لا يُضيع البيانات، لكن العلامة تبقى معلّقة إلى أن تنتهي المعاملة.
• الأسماء ليست ملزَمة بأن تكون فريدة. إذا عرّفت SAVEPOINT s مرتين، فإن ROLLBACK TO s سيرجع إلى أحدثها. هذا مفيد في حالات الاستدعاء التكراري، لكنه يصبح مربكاً إذا حدث بالخطأ.

الخطوة التالية: العروض (Views)

نقاط الحفظ تمنحك تحكّماً أدقّ في عمليات الكتابة. الخطوة التالية تتعلّق بتشكيل طريقة القراءة — أي حفظ استعلام ككائن مُسمّى قابل لإعادة الاستخدام، تُنفّذ عليه SELECT كأنه جدول. هذا ما يُعرف بـ View، وسنتناوله بعد قليل.