نستخدم واجهات برمجة تطبيقات إشعارات Discourse واستعلامات Data Explorer، ونلاحظ سلوك تجميع/توحيد الإشعارات في الحالات التالية:
-
إشعارات الرد/التعليق (
notification_type = 2) -
إشعارات التفاعل (
notification_type = 25)
السلوك الملاحظ
-
حتى مع وجود ردود/تعليقين فقط على نفس الموضوع/المشاركة خلال فترة زمنية قصيرة، يتم توحيد/تجميع الإشعارات.
-
لا يتم إنشاء صفوف إشعار منفصلة دائمًا للإجراء الثاني.
-
يبدو أن صفوف الإشعارات الموجودة يتم تحديثها/استبدالها بدلاً من إدراج صفوف جديدة.
-
تختفي صفوف الإشعارات الأقدم أحيانًا من جدول
notifications. -
تظهر إشعارات التفاعل أيضًا موحدة بشكل مماثل.
-
قد يعرض واجهة المستخدم أرقامًا مجمعة مثل “ردود 2” بينما يعكس قاعدة البيانات/واجهة برمجة التطبيقات صف إشعار واحد فقط.
وجدنا هذه الإعدادات:
-
linked notifications consolidation window mins -
likes notification consolidation window mins -
notification_consolidation_threshold
أسئلة
-
هل ترتبط هذه الإعدادات فقط بتجميع واجهة المستخدم، أم أنها تتحكم أيضًا في توحيد الإشعارات على مستوى قاعدة البيانات/واجهة برمجة التطبيقات؟
-
بما أن الإشعارات يتم توحيدها حتى مع وجود إجراءين فقط، هل يعيد Discourse استخدام/تحديث صفوف الإشعارات الموجودة داخليًا قبل الوصول إلى عتبة التوحيد؟
-
هل توجد طريقة مدعومة لتعطيل توحيد الإشعارات بالكامل بحيث ينشئ كل رد/تفاعل سجل إشعار منفصل؟
-
هل تم تصميم جدول
notificationsعمدًا ليكون غير مخصص للإضافة فقط (non-append-only) للإشعارات المرتبطة/التفاعلات؟ -
بالنسبة لإشعارات التفاعل (
notification_type = 25)، هل توجد طريقة موثوقة ومدعومة لتحديد المستخدم الذي قام بالتفاعل من حمولة الإشعار/واجهة برمجة التطبيقات؟
نحاول في المقام الأول فهم السلوك المقصد لنظام الإشعارات وما إذا كانت الإشعارات المستقلة تمامًا لكل إجراء مدعومة.