عند استدعاء نقطة النهاية /polls/voters.json، باستخدام التقسيم إلى صفحات، وجدنا أن الاستدعاء الأول يُرجع 25 مستخدمًا كما هو متوقع، ولكن الصفحة الثانية تُرجع 26 مستخدمًا، تم إرجاع أحدهم في الاستدعاء الأول. هذا ثابت كلما كان هناك أكثر من 25 مستخدمًا.
WHERE pv.poll_id IN (:poll_ids)
/* where */
) v
ORDER BY digest, CASE WHEN rank = 'Abstain' THEN 1 ELSE CAST(rank AS integer) END, username
LIMIT :limit OFFSET :offset
SQL
شكراً على الرد السريع!
سأحاول إعداد بيئة، لم أكن أرغب في تقديم طلب سحب (PR) دون اختبار. أي شخص يشعر بالحرية في أن يسبقني. أنا لست مطور روبي على الإطلاق. أنا أيضًا لا أعرف شيئًا عن تغيير المواصفات أو الاختبارات.
من المضحك أنه في واجهة المستخدم يوجد كود يقوم بتفريغ النتائج في مجموعة لتجاوز هذه المشكلة.
الأمر أكثر إضحاكًا من ذلك. لقد قدمت طلبين كبيرين جدًا لتحديث الواجهة الأمامية وإضافة التصويت الترتيبي.
لقد ساهم الحجم الهائل لتلك الطلبات بالتأكيد في تفويتي لهذا الأمر، ولم تكن إصلاحات الواجهة الخلفية ضمن النطاق حقًا (على الرغم من أنني أثناء معالجة تلك الطلبات قمت بالفعل بحل العديد من المشكلات التي لم يكن من المفترض أن تعالجها تلك الطلبات).
أعترف بأنني اتبعت سابقة الواجهة الأمامية تلك التي تم وضعها في عام 2018 للتصويت الترتيبي دون التفكير حقًا في الأمر . (والتي اتبعتموها أيضًا، وإن كان عن علم )
من المدهش كيف يمكن للحلول البديلة أن تستمر دون تحديد المشكلة الأساسية.
في طلب السحب هذا، أضفت أولاً اختبارات تعيد إنتاج المشكلة، ثم طبقت إصلاح روب البسيط ونجحت الاختبارات.
حاولت أيضًا الحل الأكثر أناقة (الذي كنت سأفضله)، ولكن على الرغم من أنه يمنع الناخبين المكررين، إلا أنه يغير أيضًا الناخب الذي يتم إرجاعه في كل صفحة، بما في ذلك الصفحة الأولى، مما قد يعتبر تغييرًا جذريًا (اعتمادًا على كيفية تعامل الواجهة الأمامية معه - لم ألقِ نظرة بعد).
بالعودة إلى الوراء، أتساءل ما هو المعنى الحقيقي لمعامل limit عند استدعاء نقطة النهاية هذه - فهو لا يحد حقًا من عدد الناخبين الإجماليين الذين تم إرجاعهم، بل يحد فقط من عدد الناخبين الذين تم إرجاعهم لكل خيار من خيارات الاستطلاع. يمكنك رؤية هذا التأثير في الاختبار الذي أضفته للاستطلاع متعدد الخيارات هنا - الصفحة الأولى محدودة بالفعل بناخبين اثنين لكل خيار، ولكن في المجموع، يتم إرجاع ثلاثة ناخبين مختلفين (موزعين عبر الخيارات). التبديل إلى الحل الأنيق (أي استخدام LIMIT :limit OFFSET :offset) يؤدي إلى تطبيق limit على العدد الإجمالي للأصوات وليس الناخبين. لست متأكدًا بنسبة 100٪ ما إذا كان هذا أفضل أو أكثر بديهية.
على أي حال، أنا جديد في هذا وقد أكون أبالغ في التفكير. الحل البسيط يزيل الناخبين المكررين ولا يسبب الكثير من الفوضى، لذا قد يكون هو الطريق الصحيح. سأنتظر المدخلات قبل تقديم طلب سحب إلى المستودع الرئيسي.
–
على الهامش، أعتقد أن هناك خطأ آخر في هذا الجزء من الكود. الاستعلام لتحميل الناخبين مرتب حسب الهضم (digest) والرتبة (rank) واسم المستخدم - ولكن عند الترتيب حسب الرتبة، فإنه يستخدم هذا الشرط:
CASE WHEN rank = 'Abstain' THEN 1 ELSE CAST(rank AS integer) END
ومع ذلك، فإن ’Abstain’ يقابل فعليًا الرتبة 0، وليس 1 - يمكن أيضًا إرجاع الرتبة 1 كـ ’1’. هذا يجعل الترتيب غير حتمي عبر الاستعلامات، مما يعني أنه اعتمادًا على عدد الناخبين وقيمة limit المستخدمة، قد يكون من الممكن فعليًا تفويت الناخبين عند إجراء استعلامات مرقمة. في اختباراتي الجديدة، اضطررت إلى فرز الناخبين المرتجعين للتغلب على الطبيعة غير الحتمية. (نظرًا لأنها غير حتمية، أفترض أنه ليس من السهل إعادة إنتاجها في اختبار، ولكن يمكنني محاولة ذلك…)
لقد اتبعت الرابط أعلاه لتقرير سابق، والذي يتضمن رابطًا إلى تقرير سابق سابق والذي يتضمن شيئًا يبدو أنه يشير إلى هذا الاحتمال أيضًا:
ومع ذلك، فقد مر وقت طويل جدًا، لذا قد يكون الكود مختلفًا تمامًا في ذلك الوقت. (حاولت العودة بالزمن باستخدام Git ولكن التاريخ توقف في عام 2021، لذا أفترض أن الكود قد انتقل في مرحلة ما.)
بعد بعض التجارب، لم أتمكن من إنشاء اختبار يتسبب في مشكلة في الترتيب غير الحتمي مع الناخبين المرتجعين. أعتقد أن هذا يرجع إلى الطريقة التي تم بها إنشاء الاستعلام وإلى كيفية إنشاء أصوات الاستطلاع، لكنني لست متأكدًا بنسبة 100٪.
. (والتي اتبعتموها أيضًا، وإن كان عن علم 
)
