صدور Polars 2.0 النهائي: محرك البث افتراضي وترتيب الصفوف لم يعد مضمونًا
المغزى: الكود الذي ينكسر يُعلن عن نفسه، أما الكود الذي يتغير ترتيب نتائجه فيمر في الـ CI ويصل إلى التقارير، فتصبح الترقية مراجعة للكود لا تحديثًا لرقم نسخة.
صدر الإصدار النهائي من مكتبة Polars 2.0 لمعالجة البيانات في 6 أكتوبر 2026، بعد أسابيع من أول release candidate الذي جعل محرك البث افتراضيًا. ويحمل الإصدار تغييرًا قد يفسد النتائج دون أن يظهر أي خطأ.
فمحرك البث (streaming engine) صار الافتراضي عند استدعاء collect() على LazyFrame. ويقول إعلان الإصدار إن هذا المحرك “لا يضمن ترتيب الصفوف افتراضيًا” في عمليات معينة، منها join وgroup_by وunpivot.
والإعلان لا يقول إن الكود سيتوقف، بل إن الصفوف قد تعود بترتيب مختلف. وهذا أخطر من الانكسار. فالكود الذي ينكسر يكشف نفسه فورًا، أما الكود الذي يتغير ترتيب نتائجه فيجتاز اختبارات الـ CI، ثم يصل إلى تقرير، أو إلى أول صف يُؤخذ عبر head(1) بعد التجميع.
والحل الذي يوثّقه المشروع هو إضافة maintain_order=True في المواضع التي يهم فيها الترتيب.
وفي الإصدار تغيير ثانٍ أقل خطورة وأكثر فائدة: العمل خارج الذاكرة (out-of-core) صار تلقائيًا. فحين يبلغ استهلاك الذاكرة نحو 80% من الـ RAM، يبدأ المحرك بنقل البيانات إلى القرص، بميزانية قرص افتراضية قدرها 64 جيجابايت. ويعني ذلك أن الاستعلام الذي كان يتوقف بخطأ out of memory صار يكتمل، أبطأ، لكنه يكتمل.
وبذلك ينقسم أثر الترقية بحسب طبيعة العمل. فمن يعالج بيانات أكبر من ذاكرة جهازه يحصل على مكسب مباشر. أما الفرق التي تعتمد في الـ pipeline على ترتيب الصفوف، خصوصًا بعد group_by، فالترقية بالنسبة لها مراجعة للكود قبل أن تكون تحديثًا لرقم نسخة.