NDJSON को YAML में बदलें

स्ट्रक्चर्ड लॉगिंग पूरे दस्तावेज़ एक फ़ील्ड के भीतर रखती है। कोई स्टैक ट्रेस, बनाया गया SQL स्टेटमेंट, अनुरोध का बॉडी — हर एक नई-लाइन वाला पाठ है, और JSON में नई-लाइन रखने का बस एक तरीक़ा है: बैकस्लैश और n दो अक्षर लिखना। इसलिए चालीस-फ़्रेम का Python ट्रेसबैक एक लाइन में हज़ारों अक्षरों की शक़्ल में आता है, हर फ़्रेम के बीच \n लिए हुए।

YAML के पास दूसरा रास्ता है और यह कन्वर्ज़न वही इस्तेमाल करता है। नई-लाइन वाली हर स्ट्रिंग ब्लॉक स्केलर के रूप में लिखी जाती है: की, फिर |-, फिर असली लाइनें इंडेंट होकर नीचे। ट्रेस ट्रेस जैसी दिखने लगती है। मान में कुछ नहीं बदलता — वही अक्षर अंदर जाते और बाहर आते हैं — पर फ़ाइल पढ़ने वाले से लड़ना बंद कर देती है।

लाइन-सीमित स्रोत को देखकर कोई YAML लेखक उम्मीद रखेगा कि हर रिकॉर्ड का अपना दस्तावेज़ हो, बीच में तीन डैश हों। यहाँ वैसा नहीं बनता। पूरी फ़ाइल एक दस्तावेज़ बन जाती है जिसमें एक सूची है, हर रिकॉर्ड एक डैश से शुरू होकर उसके नीचे इंडेंट हुए फ़ील्ड लिए।

इस चुनाव का एक असर जानने लायक़ है। यह साइट कई-दस्तावेज़ वाली YAML धारा को पढ़ती ही नहीं — वह कन्वर्ज़न रुक जाता है, कोई एक दस्तावेज़ चुनकर नहीं चलता — इसलिए एक-दस्तावेज़ वाला रूप ही वह है जो सही तरह वापस पढ़ा जाता है। साथ ही यह एक ही मान बनता है, जो स्क्रिप्ट में किसी YAML लोडर की उम्मीद होती है: `yaml.safe_load` एक सूची देता है, कोई जनरेटर नहीं जिसे बार-बार घुमाना पड़े।

बिना-कोट वाला YAML मान पार्सर सुलझाता है, इसलिए जिस भी मान की बिना-कोट शक़्ल किसी और प्रकार में बदल सकती है उसे कोट करना पड़ता है। यह लेखक बस वे मामले कोट करता है जो निर्यात किए डेटा के लिए मायने रखते हैं: अंकों जैसी स्ट्रिंग, हैश या तारे से शुरू होता मान, कोलन-और-स्पेस वाला मान। "00412" के रूप में रखा आर्डर नंबर कोट में आता है और अपने शुरुआती शून्य बचाए रखता है।

यह लेखक की सावधानी है, फ़ॉर्मेट की सुरक्षा नहीं, और यह फ़र्क़ तब मायने रखता है जब बाद में कोई फ़ाइल हाथ से बदले। "00412" के इर्द-गिर्द के कोट हटा दीजिए और अगली बार लोड होने पर वह संख्या 412 बन जाएगी।

फ़ाइल YAML 1.2 के लिए लिखी जाती है, जहाँ सिर्फ़ true और false बूलियन हैं। उस नियम के तहत NO, yes, on, off साधारी स्ट्रिंग हैं और सही तरह बिना-कोट लिखे जाते हैं। वही फ़ाइल PyYAML, Ruby के Psych या किसी पुराने Go लोडर से पढ़िए तो वे बूलियन बन जाते हैं, क्योंकि वे YAML 1.1 लागू करते हैं।

किसी कॉन्फ़िग फ़ाइल में यह नज़र आ जाता क्योंकि उसे पढ़ा जाता है। किसी एक्सपोर्ट में नहीं होता: तीस हज़ार पंक्तियों में कहीं ISO कोड वाले कॉलम में एक NO है, और लोड होते ही वह False बन जाता है बिना कुछ बताए। अगर YAML किसी 1.1 पार्सर के लिए है, तो लोड करने से पहले उस कॉलम को कोट कीजिए, या JSON रखिए जहाँ यह अस्पष्टता कहीं नहीं है।

लाइन-सीमित एक्सपोर्ट के हर बड़े लोकप्रिय गंतव्य सपाट कर देते हैं। CSV, TSV, XLSX, SQL और Parquet सब नेस्टेड `request` ऑब्जेक्ट को `request.method` और `request.path` जैसे कॉलमों में बदल देते हैं। यहाँ ऐसा कुछ नहीं होता।

चार परत गहरे `context` ब्लॉक वाला रिकॉर्ड चार परत गहरा ही, इंडेंट होकर आता है। सरणियाँ डैश वाली सूचियाँ बन जाती हैं। अलग-अलग फ़ील्ड रखने वाले रिकॉर्ड अलग-अलग फ़ील्ड ही रखते हैं — कोई की-यूनियन नहीं, कोई ख़ाली सेल नहीं। किसी एक्सपोर्ट को पढ़ने के लिए, जहाँ दिलचस्प हिस्सा कोई सबट्री हो, यही ठीक चाहिए होता है।

बिना नई-लाइन वाली पर लंबी स्ट्रिंग — कोई यूज़र एजेंट, लंबी क्वेरी वाला URL — लगभग अस्सी कॉलम पर लपेटकर की के नीचे इंडेंट लाइनों में लिखी जाती है। YAML किसी लपेटे प्लेन स्केलर के लाइन-ब्रेक को स्पेस मानता है, इसलिए वापस पढ़ने पर मान वही रहता है।

इसका मतलब यह है कि फ़ाइल में कोई URL दो लाइनों में बँटा दिख सकता है, जो पहली बार परेशान करता है और नुक़सान नहीं। ऐसा मान कॉपी करना हो तो लोड की हुई संरचना से लीजिए, पाठ से नहीं, या JSON में बदलिए जहाँ हर मान अपनी ही लाइन पर रहता है।

कुछ नहीं। जिस YAML फ़ाइल को कोई इंसान बनाए रखता है वह अपनी # वाली लाइनों से अपनी क़ीमत कमाती है जो बताती हैं कि कोई मान वैसा क्यों है, और बदली हुई एक्सपोर्ट के पास ऐसी कोई लाइन नहीं क्योंकि स्रोत के पास उन्हें रखने की जगह ही नहीं थी।

फ़ाइल एक बार पढ़कर मिटाने के लिए यही सही नतीजा है। अगर YAML किसी रिपॉज़िटरी में जाने वाली है, तो यह ग़लत नतीजा है, क्योंकि अगला पढ़ने वाला बिना किसी सन्दर्भ के रिकॉर्ड पाएगा। कमिट करने से पहले ऊपर तीन टिप्पणी-लाइनें जोड़ना कुछ ख़र्च नहीं करता।

ख़ाली लाइनें छोड़ दी जाती हैं, आख़िर की नई-लाइन सहित, इसलिए सूची में प्रविष्टियों की गिनती स्रोत की गैर-ख़ाली लाइनों जितनी होती है। जो लाइन मान्य JSON नहीं है वह कन्वर्ज़न को उसकी संख्या के साथ रोक देती है, चुपचाप छोड़ी नहीं जाती।

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

मुफ़्त सीमा 100 MB है और पूरी फ़ाइल कुछ भी लिखने से पहले याददाश्त में पार्स होती है, इसलिए व्यावहारिक सीमा किसी कोटा से ज़्यादा ब्राउज़र टैब की है। कई मेगाबाइट बिना शिकायत बदल जाते हैं।

समझदार सीमा तकनीकी सीमा से नीचे है, क्योंकि इस लक्ष्य का मक़सद पढ़ना है। कोई तीस हज़ार रिकॉर्ड नहीं पढ़ता — पहले फ़िल्टर कीजिए, `jq -c 'select(.level=="error")'` एक सेकंड लेता है और वे चालीस रिकॉर्ड छोड़ता है जो आप असल में चाहते थे।

इसी ब्राउज़र टैब में, साधारी JavaScript से। कुछ अपलोड नहीं होता, कोई इंजन पहले डाउनलोड नहीं करना, कोई खाता नहीं, और चलते हुए नेटवर्क टैब इसी बात का सबूत है, इस पैराग्राफ़ का नहीं।

यह इस जोड़े के लिए ज़्यादा मायने रखता है। यहाँ जो फ़ाइलें बदली जाती हैं वे एरर एक्सपोर्ट और घटना-डंप हैं, और उनमें वह सब होता है जो टूटने के वक़्त चल रहा था — अनुरोध पथ, सत्र पहचानकर्ता, कभी-कभी क्वेरी-स्ट्रिंग में कोई टोकन जिसे लॉग नहीं होना चाहिए था। ऐसी चीज़ किसी वेब सेवा में पेस्ट करने लायक़ नहीं, और यहाँ पेस्ट करने को कुछ है ही नहीं।