SQL Formatter

यह किसके लिए है?

SQL एक one-liner से लेकर 200-line analytics query तक होता है जिसे कोई भी सही ढंग से indent होने तक नहीं पढ़ सकता। यह formatter किसी भी SELECT, INSERT, UPDATE, या DDL को लेता है और सुसंगत indentation, हर clause से पहले line breaks, और एक समान keyword casing के साथ फिर से लिखता है। Minify mode इसके विपरीत करता है — code या scripts में embed करने के लिए सब कुछ एक line में दबा देता है। पूरी चीज़ आपके browser में चलती है; queries कभी page से बाहर नहीं जातीं।

कब इस्तेमाल करें

• एक log file, ORM, या chat message से copy की गई query को कुछ diff-able और review-able में reformat करना।
• एक migration script commit करने से पहले team conventions (UPPERCASE keywords, 2-space indent) को normalise करना।
• एक लंबी pretty-printed query को एक line में squash करना ताकि यह एक YAML config या one-line CLI argument में fit हो।
• संरचनात्मक समस्याओं को देखना — unbalanced parens, SELECT list में एक missing comma, या बिना ON वाला JOIN — जो query indent होने पर स्पष्ट होती हैं।

आम गलतियाँ

• Formatter structural है, semantic नहीं। यह आपको नहीं बताएगा कि query सही SQL है या नहीं, केवल कैसे देखे गए tokens को indent करना है। input में एक syntax error output में एक syntax error बन जाता है।
• Dialect-specific keywords अलग होते हैं। ILIKE, RETURNING, LATERAL Postgres हैं; STRAIGHT_JOIN, SQL_CALC_FOUND_ROWS MySQL हैं। सही dialect चुनें या वे शब्द keywords के रूप में पहचाने नहीं जाएंगे।
• String literals हूबहू संरक्षित किए जाते हैं। single quotes में एक multi-line string अपने line breaks को बनाए रखती है; formatter '...' के अंदर text को reflow नहीं करता।
• Comments बचे रहते हैं पर अपनी lines पर अलग हो जाते हैं। यदि आपके पास एक -- inline comment mid-line था, तो वह pretty-print के दौरान अपनी line पर चला जाएगा।
• Minify comments को हटा देता है। यदि आपको इनकी ज़रूरत है, minify न करें।
• यह एक linter नहीं है। CI में validation, style enforcement, और dialect checking के लिए एक वास्तविक SQL parser (जैसे sqlfluff) का इस्तेमाल करें।