آلية العمل

يقوم التطبيق باستخدام إصدار معدّل من مكتبة SQLite حيث يحتوي على برمجية LiteSync للولوج إلى قاعدة البيانات.

تعديلات مكتبة SQLite هي تعديلات داخلية فقط، فبذلك تبقى الواجهة كما هي.

تقوم مكتبات LiteSync بالتواصل فيما بينها، متبادلة بذلك بيانات المناقلات.






النسخ

عند أوّل تشغيل، يقوم التطبيق بالاتصال بباقي العقد وتنزيل نسخة محدثة عن قاعدة البيانات

في الطوبولوجيا المركزية، تقوم العقدة الأساسية بإرسال نسخ عن قاعدة البيانات إلى بقية العقد.

بعد انتهاء التنزيل، تبدأ العقدة بالمزامنة



المزامنة

عند امتلاك جميع العقد لنفس قاعدة البيانات، تبدأ العقد بالقيام بمناقلات التبادل التي تم طلب تنفيذها أثناء وجود العقد في حالة عدم الاتصال

بعد ذلك، تدخل العقد في وضع الاتصال وحالما يبدأ تنفيذ مناقلة جديدة في عقدة ما، يتم نقل هذه المناقلة إلى باقي العقد المتصلة كيف تقوم بتنفيذها

إن لم تكن العقدة متصلة، يتم تخزين المناقلة على سجل محلي كي يتم إرساله في وقت لاحق.



هل أحتاج للقيام بتغيرات على كود تطبيقي؟

هنالك بعض الخطوات لكن بشكل أساسي، يتوجب تغيير سلسلة URI في بادئة قاعدة البيانات من هذا:

“file:/path/to/app.db”

إلى ما يماثل هذا:

“file:/path/to/app.db?node=secondary&connect=tcp://server.ip:1234”

لكن LiteSync يستخدم واجهة SQLite3 الأصلية؛ فلا حاجة لاستخدام API أخرى.



الاتصال

تملك كل عقدة خيارين:

الربط بعنوان
الاتصال بعنوان القرين

مما يمكنك من اختيار أحد الطرفين كي يتصل بالآخر. تكمن فائدة هذا في حال كان أحد الطرفين وراء موجه أو جدار ناري.



الطوبولوجيا المدعومة


الطوبولوجية النجمية المركزية


يكون ليدنا في هذه الطوبولجيا عقدة أساسية تتصل بها باقي العقد، لذلك يجب أن تكون هذه العقدة في ضع الاتصال لكي يتم التزامن بين العقد

أمثلة تكوين وفق الطوبولوجيا النجمية


يمكن للعقدة الأولية أن ترتبط بعنوان، وتقوم العقدة الثانوية بالاتصال بالعقدة الأولية

عقدة أولية:

"file:/home/user/app.db?node=primary&bind=tcp://0.0.0.0:1234"

عقدة ثانوية (على جهاز آخر):

"file:/home/user/app.db?node=secondary&connect=tcp://server:1234"


كما يمكن لهذه العقدة الأولية الاتصال بعقد ثانوية أخرى

عقدة أولية

"file:/home/user/app.db?node=primary&connect=tcp://address1:port1,tcp://address2:port2"

عقد ثانوية (كل عقدة موجودة على جهاز):

"file:/home/user/app.db?node=secondary&bind=tcp://0.0.0.0:1234"


كمان يمكن استخدام مزيج من الخيارين

عقدة أولية:

"file:/home/user/app.db?node=primary&bind=tcp://0.0.0.0:1234&connect=tcp://address1:port1"

العقدة الثانوية 1:

"file:/home/user/app.db?node=secondary&connect=tcp://server:1234"

العقدة الثانوية 2:

"file:/home/user/app.db?node=secondary&bind=tcp://0.0.0.0:1234"



حالة التزامن

يمكن التحقق من حالة التزامن باستخدام الأمر التالي:

PRAGMA sync_status

حيث يردّ بسلسلة محارف JSON.



التحقق من جهوزية قاعدة البيانات

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

يمكن الحصول على حالة التزامن و التحقق من المتحولdb_is_ready (الذي يدلّ على جهوزية قاعدة البيانات)

طالع هذه الأمثلة الأساسية



كيف أستطيع استخدامه في تطبيقاتي؟

تستطيع القيام بذلك عبر ثلاث خطوات:

1  استبدل مكتبة SQlite بتلك التي تحتوي LiteSync

2  قم بتغيير سلسلة اتصال URI

3  تحقق من جهوزية قاعدة البيانات

عند القيام بترجمة تطبيقات C وC++ تأكد من ربط تطبيقك مع مكتبة LiteSync

أما بالنسبة للغات الأخرى، تأكد من تثبيت الـwrapperالمناسب بكل لغة



نموذج لعقدة أولية

يمكن للعقدة الأولية أن تكون تطبيقاً، تماماً كتطبيق العقدة الثانوية لكن مع اختلاف سلسلة URI.

أو نقوم باستخدام تطبيق مخصص بالعقدة الأولية.

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

اختر لغة -->



نموذج تطبيق بسيط

يكون التطبيق الذي يقوم بالكتابة إلى قاعدة بيانات محلية كالتالي:

اختر لغة -->



القيود الحالية

1  تجنب استخدام الدوال التي تعيد قيم مختلفة من أجل كل تنفيذ. كما في random() و date('now')

2  الكلمة المفتاحية AUTOINCREMENT غير مدعومة.

3  يجب استخدام اتصال واحد فقط لكل ملف قاعدة بيانات. لا يجب السماح لعدة تطبيقات بالولوج إلى نفس ملف قاعدة البيانات.يتوجب على كل تطبيق أن يستخدم ملف قاعدة البيانات خاص به، إذ يتم نسخها و مزامنتها عبر LiteSync.