> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Demo days - 2026-09-10
> ClickStack demo days بتاريخ 2026-09-10
عوامل تصفية لوحة المعلومات المطلوبة
*عرض توضيحي من قبل [@pulpdrew](https://github.com/pulpdrew)*
أصبح بالإمكان الآن تحديد عوامل تصفية لوحة المعلومات كمطلوبة، بحيث لا تُحمَّل البطاقات إلى أن تُحدَّد قيمة لها. في السابق كان كل عامل تصفية اختياريًا، وكان فتح لوحة معلومات مبنية على مصدر كبير يؤدي إلى تشغيل جميع بطاقاتها دون تصفية قبل أن تحصر نطاق البحث.
يتضمن تعريف عامل التصفية مفتاح تبديل جديدًا باسم **Required**. وهو بمفرده يحجب البطاقات التي تستخدم عامل التصفية فعليًا: تلك التي تشير إليه كمتغير، وتلك التي تتلقى منه قيمة عبر البث. في العرض التوضيحي، أدى عامل تصفية باسم الخدمة يُبَث إلى مصدري السجلات والتتبعات إلى حجب كل بطاقة في لوحة المعلومات، بينما أدى عامل تصفية للخطورة موجود فقط في جدول السجلات إلى حجب بطاقات السجلات مع ترك بطاقات التتبع تُحمَّل كما في السابق.
ويوسّع خيار ثانٍ هذا الشرط ليشمل كل بطاقة في لوحة المعلومات، سواء استخدمت البطاقة عامل التصفية كمتغير أو تلقت منه قيمة عبر البث أم لا. وعلى المستوى الداخلي، حصل كل نوع من عوامل التصفية على حقلين: `minSelections`، حيث تعني القيمة 1 أنه مطلوب، و`isGlobalRequirement` للنسخة الشاملة للوحة المعلومات. و`minSelections` رقم وليس قيمة منطقية، بحيث يبقى من الممكن لاحقًا إضافة حد أقصى مقابل `maxSelections`، وحدود دنيا أكبر من 1.
ولا تُحجب عوامل التصفية التابعة حتى الآن بعوامل التصفية المطلوبة التي تعتمد عليها، لذا فإن عامل التصفية الذي يشير استعلام خياراته إلى متغير مطلوب سيظل يستعلم عن خياراته قبل أن تكون لذلك المتغير قيمة.
كما تنطبق الآن اختيارات عوامل تصفية لوحة المعلومات والمتغيرات على معاينة المخطط في محرر البطاقة، وفق ما اقترحه Brandon أثناء مراجعة طلب سحب عوامل التصفية المطلوبة. في السابق كانت المتغيرات وعوامل التصفية الأساسية تُنقل إلى المعاينة بينما لم تكن عوامل تصفية البث كذلك، وهو ما كان يمثل تناقضًا، ومع وجود عوامل التصفية المطلوبة صار هناك مبرر متعلق بالأداء لتحرير البطاقة بعوامل التصفية نفسها التي تطبقها لوحة المعلومات. ومفتاح التبديل **Apply filters** مفعّل افتراضيًا، ويمكنك إيقافه لرؤية البطاقة بالحالتين.
ويُفرض إيقاف مفتاح التبديل عندما تكون البطاقة مهيأة بتنبيه، لأن التنبيهات تُقيَّم دون تطبيق أي عوامل تصفية، وبهذا تطابق المعاينة ما سيستعلم عنه التنبيه فعليًا.
وعندما يحجب عامل تصفية مطلوب المعاينة، تشير الرسالة في محرر البطاقة الآن إلى إيقاف **Apply filters** كوسيلة لتجاوز الحجب.
**طلبات السحب ذات الصلة:** [#3078](https://github.com/hyperdxio/hyperdx/pull/3078) دعم تهيئة عوامل تصفية لوحة المعلومات كمطلوبة، [#3093](https://github.com/hyperdxio/hyperdx/pull/3093) تطبيق عوامل تصفية لوحة المعلومات اختياريًا على معاينة محرر البطاقة، [#3098](https://github.com/hyperdxio/hyperdx/pull/3098) إضافة getBlockingRequiredFilterNames وتحديث نص الحجب في محرر البطاقة
تقدّم الاستعلام الحيّ في صفحة البحث
*عرض توضيحي من قبل [@wrn14897](https://github.com/wrn14897)*
في السابق، كان البحث البطيء يُظهر مؤشر دوران غير محدّد طوال مدته، ولم تكن هناك أي طريقة لمعرفة ما إذا كان ClickHouse قد أنجز 5% أو 95% من النطاق، أو ما إذا كان يعمل فعلًا من الأساس، وهو بالضبط ما يحدث عندما يكون لدى الـ source مفتاح أساسي لا يناسب الـ query. أما الآن، فيعرض footer جدول النتائج وشريط الصفوف المفحوصة والزمن المنقضي في المُدرَّج التكراري عدّادات التقدّم الخاصة بـ ClickHouse نفسه: مدة تشغيل الـ query، وعدد الصفوف التي تم فحصها، ونسبة مئوية؛ وهو ما يقترب من الذي يعرضه ClickHouse CLI أثناء تدفّق الـ query.
يأتي التقدّم من صيغة `JSONEachRowWithProgress`، التي تُضمّن أسطر `{"progress":...}` بالتناوب مع الصفوف في جسم الاستجابة. أما الـ headers فكانت طريقًا مسدودًا: إذ يتوقف ClickHouse عن إصدار `X-ClickHouse-Progress` بمجرد بدء الـ body، كما أن `fetch()` لا يستطيع إظهار الـ headers تدريجيًا على أي حال. وتتطلب هذه الصيغة ClickHouse 25.1 أو أحدث، لذا يتم اختيارها لكل اتصال بناءً على إصدار الخادم المُبلَّغ عنه، بينما تبقى الخوادم الأقدم أو غير المعروفة على المسار الحالي غير المتدفّق.
تجلب صفحة البحث نافذة زمنية واحدة في كل مرة بدلًا من النطاق بالكامل دفعة واحدة، وبذلك يُنفَّذ البحث الممتد لأسبوع يومًا بيوم ويتوقف عند الحصول على عدد كافٍ من الصفوف. ويُحسب التقدّم على مجموعة النوافذ كلها، وقد صُمّم ليستمر عبر الفجوات بينها بشكل متعمّد: فمسحه عند تلك الحدود كان يؤدي إلى اختفاء الشريط وإعادة تشغيل مؤقّت الزمن المنقضي عند كل نافذة، عشرات المرات على مدى نطاق يمتد شهرًا. وتسجّل كل نافذة نفسها بأنها قيد التنفيذ عند 0% قبل أن تبدأ القراءة، حتى لا تُنسب إلى نافذة فُتحت للتوّ كامل نطاقها.
وتتوفر هذه الميزة في صفحة البحث الرئيسية فقط، وهي مخفية أثناء التتبّع الحيّ، حيث يُعاد جلب الـ query كل بضع ثوانٍ ولن يؤدي الشريط إلا إلى الوميض. ومع النافذة الأولى القصيرة، فإن البحث الذي يستوفي `LIMIT` فورًا يُظهر نحو 0% لوهلة قبل أن يختفي الشريط.
ما يتدفّق هو التقدّم، لا النتائج. فالصفوف لا تزال تصل نافذةً بنافذة، وإرجاعها أثناء فحصها يتطلب دعم التدفّق في جانب ClickHouse، وهو أمر قيد العمل عليه، كما سأل Jordan في الاتصال. ويضيف الـ proxy الموجود بينهما تعقيدًا خاصًا به هناك، لذا لم يُنفَّذ بعد.
وفي التقسيم إلى مقاطع نقص مرتبط بذلك ورد كملاحظة: ففي حين يُملأ المُدرَّج التكراري مقطعًا بمقطع، لا شيء يميّز نافذة لا يزال يجري الاستعلام عنها من أخرى لم تُرجع أي بيانات، وسيكون من المفيد وجود مؤشر ما للتقدّم على الـ مخطط نفسه. لكن هذا يقع في جزء من الشيفرة مختلف عن هذا التغيير.
**طلبات السحب ذات الصلة:** [#3103](https://github.com/hyperdxio/hyperdx/pull/3103) عرض تقدّم الـ query الحيّ في ClickHouse أثناء البحث (مفتوح). أما تقسيم البحث إلى نوافذ يومية الذي يعرض الشريط تقدّمه عليه فهو عمل أقدم وليس جزءًا من هذا التغيير؛ فقد أُضيفت نوافذ البحث التدريجية في [#1125](https://github.com/hyperdxio/hyperdx/pull/1125) وتقسيم الـ مخطط إلى مقاطع في [#1233](https://github.com/hyperdxio/hyperdx/pull/1233).