Large-language-model (LLM) एजेंटों द्वारा तैयार किए गए Oracle SQL स्क्रिप्ट्स कागज़ पर दोषरहित लग सकते हैं, लेकिन प्रोडक्शन में वे विफल हो सकते हैं। एक 2.3 मिलियन-लाइन के लेगेसी कोडबेस में, एक AI-संचालित एजेंट नियमित रूप से ऐसे आइडेंटिफायर्स (identifiers) का उपयोग कर रहा था जो मौजूद ही नहीं थे – उदाहरण के लिए, वास्तविक STATUS_CD कॉलम के बजाय POLICY_STATUS का उपयोग करना, या CUSTOMER के बजाय एक गैर-मौजूद CUSTOMERS टेबल का संदर्भ देना।
टाइपो (typo) पकड़ने के लिए स्क्रिप्ट चलाना UPDATE या DELETE स्टेटमेंट्स के लिए कोई विकल्प नहीं है। उन्हें प्रोडक्शन जैसे डेटासेट पर चलाने से लॉक्स (locks) लग जाते हैं, सीक्वेंस नंबर खर्च हो जाते हैं और यह कैस्केडिंग साइड-इफेक्ट्स को ट्रिगर कर सकता है। डेवलपर्स को बिना किसी डेटा को छुए नामों और सिंटैक्स को वैलिडेट करने का एक तरीका चाहिए। इसका उत्तर, आश्चर्यजनक रूप से सरल है, Oracle का EXPLAIN PLAN कमांड है – जिसे एक लिंटिंग स्टेप (linting step) के रूप में पुन: उपयोग किया गया है।
EXPLAIN PLAN एक तेज़ वैलिडेटर के रूप में कैसे काम करता है
जब Oracle को कोई स्टेटमेंट मिलता है, तो वह सबसे पहले उसे पार्स (parse) करता है। पार्सिंग यह जाँचती है कि संदर्भित प्रत्येक टेबल, कॉलम और प्रिविलेज मौजूद है या नहीं, फिर यह एक एक्जीक्यूशन प्लान बनाता है और उस प्लान को एक सिस्टम टेबल में लिखता है। यह कमांड कभी भी स्टेटमेंट को रन नहीं करता: कोई भी रो (row) संशोधित नहीं होती, कोई ट्रिगर फायर नहीं होता, और कोई लॉक नहीं लगता। यदि पार्सर किसी अज्ञात ऑब्जेक्ट से टकराता है, तो यह कुछ मिलीसेकंड में एरर दे देता है।
यह व्यवहार EXPLAIN PLAN को AI-जनरेटेड SQL के लिए एक परफेक्ट प्री-फ्लाइट चेक बनाता है। किसी गायब टेबल या कॉलम की रिपोर्ट तुरंत मिल जाती है, जिससे जनरेशन लूप को इंसान के स्क्रिप्ट देखने से पहले ही गलती सुधारने का मौका मिल जाता है।
वह वर्कफ़्लो जिसे मैंने अपने CI पाइपलाइन में जोड़ा है
- विभाजित करें (Split): आने वाली स्क्रिप्ट को व्यक्तिगत स्टेटमेंट्स में विभाजित करें।
- चलाएं (Run): एक डेवलपमेंट स्कीमा के विरुद्ध
EXPLAIN PLAN FOR <statement>चलाएं। - इकट्ठा करें (Collect): Oracle द्वारा लौटाए गए किसी भी पार्सिंग एरर को इकट्ठा करें।
- वापस भेजें (Feed): दोबारा कोशिश करने के लिए एरर्स को LLM को वापस भेजें।
व्यवहार में, एक सिंगल रिट्राय (retry) अधिकांश नेमिंग एरर्स को ठीक कर देता है। AI सही स्कीमा सीख जाता है और अपने आउटपुट को स्वचालित रूप से एडजस्ट कर लेता है। मैंने एजेंट को रीड-ओनली मोड (read-only mode) में भी लॉक कर दिया है: यह SELECT और EXPLAIN PLAN कॉल जारी कर सकता है, लेकिन DDL, DML और COMMIT को ब्लॉक कर दिया गया है। वह सैंडबॉक्स यह गारंटी देता है कि जब तक AI उसके स्ट्रक्चर की जांच कर रहा है, डेटाबेस अप्रभावित रहे।
नामों की जांच के अलावा, जनरेट किया गया प्लान स्पष्ट परफॉरमेंस रेड फ्लैग्स (red flags) को भी प्रकट करता है। यदि कोई स्टेटमेंट किसी विशाल टेबल पर फुल-टेबल स्कैन ट्रिगर करेगा, तो प्लान किसी भी रो को छूने से पहले ही इसे दिखा देता है, जिससे डेवलपर्स को इंडेक्स सुझाने या प्रेडिकेट (predicate) को फिर से लिखने का मौका मिलता है।
इस दृष्टिकोण की सीमाएं
- लॉजिकल करेक्टनेस सत्यापित नहीं होती है। एक स्टेटमेंट जो सही कॉलम का संदर्भ देता है लेकिन गलत फ़िल्टर लागू करता है, वह अभी भी लिंट पास कर लेगा।
- PL/SQL ब्लॉक्स इसके दायरे से बाहर हैं। पार्सर केवल व्यक्तिगत SQL स्टेटमेंट्स को संभालता है; प्रोसीजरल कोड के लिए एक अलग वैलिडेशन पाथ की आवश्यकता होती है।
- डेटा-लेवल वैलिडेशन की कमी है। लिंट आपको यह नहीं बता सकता कि क्या कोई लिटरल वैल्यू कॉलम के डोमेन के अनुरूप है या क्या फॉरेन-की (foreign-key) संदर्भ वास्तव में मौजूद है।
- केवल देव (Dev) स्कीमा। वे एरर्स जो केवल प्रोडक्शन में दिखाई देते हैं – उदाहरण के लिए, एक टेबल जो देव में मौजूद है लेकिन प्रोडक्शन में उसका नाम बदल दिया गया है – वे बाद तक अदृश्य रहते हैं।
ये कमियां इस पद्धति की उपयोगिता को कम नहीं करती हैं; वे केवल इसकी सीमाएं निर्धारित करती हैं। अधिकांश LLM-जनरेटेड DML स्क्रिप्ट्स के लिए, सबसे सामान्य विफलता मोड एक टाइपो या गलत ऑब्जेक्ट नाम होता है, और EXPLAIN PLAN बिल्कुल यही पकड़ता है।
अन्य डेटाबेस इंजन तक पोर्टेबिलिटी
यही सिद्धांत Oracle के परे भी लागू होता है। PostgreSQL का PREPARE स्टेटमेंट या EXPLAIN बिना एक्जीक्यूशन के क्वेरी को पार्स कर सकता है। SQL Server SET PARSEONLY ON प्रदान करता है, जो इंजन को वास्तविक प्रोसेसिंग को छोड़कर सिंटैक्स और ऑब्जेक्ट नामों को वैलिडेट करने के लिए मजबूर करता है। कोई भी RDBMS जो पार्सिंग को एक्जीक्यूशन से अलग करता है, वह एक लाइटवेट लिंटिंग गेट बन सकता है।
मुख्य निष्कर्ष
हर AI-जनरेटेड SQL स्टेटमेंट पर EXPLAIN PLAN (या इसके समकक्ष) चलाना एक डेटाबेस पार्सर को एक सस्ते, जीरो-रिस्क लिंटिंग गेट में बदल देता है। यह किसी भी डेटा के हिलने से पहले सबसे सामान्य नेमिंग और सिंटैक्स एरर्स को पकड़ लेता है, जिससे लेगेसी सिस्टम स्थिर रहते हैं और डेवलपर्स LLM-असिस्टेड कोडिंग के उत्पादकता लाभ का लाभ उठा पाते हैं।