ggsql - SQL के लिए graphics grammar

 (opensource.posit.co)
11 पॉइंट द्वारा GN⁺ 2026-04-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SQL syntax-आधारित visualization tool, जो VISUALIZE, DRAW, PLACE, SCALE, LABEL जैसे clauses के जरिए data query और graph composition को एक ही flow में जोड़ता है
  • columns को visual properties से map करके layer composition approach के साथ scatter plot, bar graph, histogram, boxplot, और annotation elements तक को एक ही structure में बनाया जा सकता है
  • SQL query results को सीधे visualization input के रूप में भेजता है, और कुछ layers single SQL query execution के जरिए सिर्फ aggregate लाती हैं, इसलिए बड़े पैमाने के data processing में फायदेमंद है
  • R या Python runtime के बिना इस्तेमाल किए जा सकने वाले छोटे और focused executable की दिशा में डिज़ाइन किया गया है, इसलिए code-based reporting tools और AI analysis assistants के integration के लिए भी उपयुक्त है
  • मौजूदा version alpha-release है, और high-performance writer, themes, interactivity, language server, formatter, spatial data support जैसी expansion plans पेश किए गए हैं

ggsql परिचय

  • ggsql SQL syntax-आधारित grammar of graphics implementation है, जो SQL में structured visualization capabilities जोड़ता है
    • Quarto, Jupyter notebooks, Positron, VS Code आदि में इस्तेमाल किया जा सकता है
  • इसे इस तरह डिज़ाइन किया गया है कि SQL users visualization code को अपने परिचित तरीके से लिख सकें
    • SQL की declarative और composable clause structure को visualization grammar पर भी लागू किया गया है
  • motivation और usage examples के साथ ggsql की core syntax को समझाया गया है

बुनियादी उदाहरण

  • पहला plot

    • built-in penguins dataset से scatter plot बनाया जा सकता है
      • VISUALIZE bill_len AS x, bill_dep AS y FROM ggsql:penguins
      • DRAW point
    • VISUALIZE में data columns को visual properties से map किया जाता है, और DRAW point उसी default mapping का उपयोग करके point layer बनाता है
    • सिर्फ species AS color जोड़ने से color categories के आधार पर भेद किया जा सकता है
      • VISUALIZE bill_len AS x, bill_dep AS y, species AS color FROM ggsql:penguins
      • DRAW point
    • DRAW smooth जोड़ने से point layer के ऊपर regression line layer जोड़ी जा सकती है
      • species के हिसाब से color mapping बनी रहती है, इसलिए हर species के लिए अलग line बनती है
    • predefined plot types की जगह modular components को जोड़ने का तरीका अपनाया गया है
    • वही structure बनाए रखते हुए visualization को पूरी तरह अलग रूप में बदला जा सकता है
      • VISUALIZE island AS x, species AS color FROM ggsql:penguins
      • DRAW bar

  • पूरा उदाहरण

    • ऊपर का हिस्सा सामान्य SQL query है, और VISUALIZE के बाद का हिस्सा visualization query के रूप में अलग होता है
      • उदाहरण में DuckDB backend का उपयोग किया गया है
    • SQL हिस्से में astronauts.parquet से हर नाम के लिए सबसे हालिया mission ही रखने हेतु ROW_NUMBER() और QUALIFY का उपयोग किया गया है
    • इसके बाद दो sets को जोड़ा जाता है
      • year_of_selection - year_of_birth को age के रूप में निकालकर Age at selection category दी जाती है
      • year_of_mission - year_of_birth को age के रूप में निकालकर Age at mission category दी जाती है
      • दोनों results को UNION ALL से जोड़ा जाता है
    • visualization query में age AS x, category AS fill mapping के बाद DRAW histogram का उपयोग होता है
      • SETTING binwidth => 1, position => 'identity' दिया जाता है
    • PLACE rule से पहले से calculated average positions के annotation जोड़े जाते हैं
      • x => (34, 44), linetype => 'dotted'
    • PLACE text से text annotations जोड़े जाते हैं
      • x => (34, 44, 60)
      • y => (66, 49, 20)
      • label में Mean age at selection = 34, Mean age at mission = 44, John Glenn was 77 on his last mission - the oldest person to travel in space! शामिल हैं
      • hjust => 'left', vjust => 'top', offset => (10, 0) दिया जाता है
    • SCALE fill TO accent से fill mapping values को accent color palette में बदला जाता है
    • LABEL clause से title, subtitle, x-axis label, और legend label नियंत्रित किए जाते हैं
      • title How old are astronauts on their most recent mission?
      • subtitle Age of astronauts when they were selected and when they were sent on their mission
      • x-axis Age of astronaut (years)
      • fill => null

visualization query structure

  • VISUALIZE से पहले का हिस्सा pure SQL है, और result table को table के रूप में लौटाने के बजाय सीधे visualization input में भेजा जाता है
  • SQL हिस्से में बने tables या CTE को visualization query में refer किया जा सकता है
  • अगर data पहले से visualization के लिए उपयुक्त format में है, तो SQL हिस्सा छोड़ा जा सकता है
    • VISUALIZE year_of_selection AS x, year_of_mission AS y FROM 'astronauts.parquet'
  • VISUALIZE या VISUALISE SQL query के अंत और visualization query की शुरुआत को दर्शाता है
  • mapping का काम columns को visual properties यानी aesthetics से जोड़ना है
    • उदाहरण में age x-axis position और category fill color से जुड़ा है
  • DRAW visualization में layers जोड़ता है
    • point जैसे simple types भी हैं, और histogram जैसे types भी जिनमें binning aggregation calculation की जरूरत होती है
    • layers उसी क्रम में render होती हैं जिसमें वे define की गई हैं
  • PLACE, DRAW का sibling clause है, जो table data की जगह literal values का उपयोग करने वाला annotation-specific clause है
    • उदाहरण वाला visualization histogram layer, rule annotation layer, और text annotation layer—इन तीन layers से बना है
    • एक layer हमेशा सिर्फ एक graphic object से मेल नहीं खाती; यह एक ही type के कई individual objects भी render कर सकती है
  • SCALE data values को aesthetic के अनुरूप values में बदलने का clause है
    • सिर्फ string categories को actual colors में बदलने तक सीमित नहीं, बल्कि continuous transformations, break point definition, और ordinal या binned जैसे scale types भी सेट कर सकता है
  • LABEL title, subtitle, axis titles, legend titles जैसे text labels जोड़ने और बदलने की सुविधा देता है

एक कदम पीछे हटकर

  • ऊपर का उदाहरण बहुत सारी syntax दिखाता है, लेकिन साथ ही core grammar के अहम हिस्सों को एक साथ समेटता है
  • कई visualization queries इससे कहीं ज्यादा simple हो सकती हैं
  • astronauts.parquet का उपयोग करके gender के अनुसार birth year का boxplot उदाहरण दिया गया है
    • VISUALIZE sex AS x, year_of_birth AS y FROM 'astronauts.parquet'
    • DRAW boxplot
  • code की लंबाई दूसरे plotting systems से ज्यादा हो सकती है, लेकिन इसमें अधिक structured, composable, और self-descriptive गुण हैं
  • ये गुण users के लिए हर तरह के plot behavior को समझना आसान बनाते हैं और भविष्य के LLM coding assistants के लिए भी फायदेमंद हैं
  • उसी संबंध को jitter scatter plot में आसानी से बदला जा सकता है
    • DRAW point
    • SETTING position => 'jitter'
  • jitter को data distribution follow कराने के लिए सेट करके violin plot जैसा behavior दिया जा सकता है
    • SETTING position => 'jitter', distribution => 'density'
  • ऐसी syntax structure और composability exploratory analysis और visualization design की iterative process को आसान बनाती है

ggsql क्यों

  • ggsql बनाने के पाँच कारण बताए गए हैं
    • मुख्य रूप से SQL के साथ काम करने वाले data analysts और data scientists को support करना
    • SQL और grammar of graphics के बीच गहरा मेल
    • R या Python जैसी पूरी programming language के बिना भी शक्तिशाली code-based visualization tool बनाना
    • LLM की बेहतरीन SQL handling क्षमता और नए visualization interfaces की संभावना
    • ggplot2 के 18 साल के development experience को नई नींव पर लागू करने का इरादा

  • Hello, SQL user

    • data science revolution के दौरान R और Python को ज्यादा ध्यान मिला, लेकिन SQL ने data work की भरोसेमंद foundation के रूप में अपनी भूमिका बनाए रखी
    • बहुत से data workers ऐसे हैं जो केवल SQL या मुख्य रूप से SQL का ही उपयोग करते हैं
    • इनके लिए उपलब्ध मौजूदा visualization choices, लेख के अनुसार, अधिकतर optimal नहीं हैं
      • data export करके R या Python का उपयोग करना
      • GUI-based BI tools का उपयोग करना, जिनमें reproducibility support कम होता है
      • query के भीतर के visualization tools का उपयोग करना, लेकिन उन्हें पर्याप्त powerful या ergonomic नहीं माना गया
    • ggsql syntax इस तरह बनाई गई है कि SQL users इसे तुरंत समझ सकें
      • composable और declarative clauses के प्रति उनकी अपेक्षाओं का लाभ उठाया गया है
    • ggsql सिर्फ visualization workflow सुधारने के लिए नहीं, बल्कि SQL users को Quarto-आधारित code-based reporting और sharing ecosystem की ओर लाने के लिए भी काम करता है

  • declarative data transformation, declarative visualization

    • SQL एक domain-specific language है जो एक या अधिक tables में stored relational data के साथ काम करती है
    • SQL syntax relational algebra की अवधारणाओं पर आधारित है और data manipulation को structure के साथ सोचने का तरीका देती है
    • SQL semantics functional नहीं बल्कि declarative modular operations के सेट को define करती है
    • grammar of graphics data visualization concepts को modular components में तोड़ने का एक theoretical framework है
    • ggplot2 जैसे tools इन concepts को practical implementation में बदलते हैं
    • grammar of graphics भी functional से ज्यादा declarative modular operations का सेट define करती है
    • दोनों systems अपने-अपने domain तक पहुँचने के तरीके में काफी समान हैं, और raw data से final visualization तक एक natural और powerful end-to-end pipeline बना सकते हैं

  • No runtime, no problem

    • ggplot2 के लिए R install होना चाहिए, और plotnine के लिए Python
    • इसके विपरीत, single focused executable पर आधारित visualization tool के स्पष्ट फायदे हैं
      • किसी दूसरे tool में एक छोटा executable embed करना, R/Python bundling या installation requirement की तुलना में आसान है
      • scope छोटा होने से malicious या accidental code execution को sandbox में सीमित करना आसान होता है
    • ये विशेषताएँ ggsql को AI analysis assistants या अलग-अलग environments में code चलाने वाले code-based reporting tools के integration के लिए ज्यादा आकर्षक बनाती हैं
    • interpreted language से बाहर निकलने पर कुछ constraints आते हैं, लेकिन लाभ भी बड़े हैं
    • सबसे महत्वपूर्ण फायदा यह है कि strict structure की वजह से backend हर layer के लिए पूरे data pipeline को single SQL query के रूप में चला सकता है
      • उदाहरण के तौर पर, 10 billion transaction rows के bar plot में data warehouse से हर bar का सिर्फ count value लिया जाएगा, पूरी 10 billion rows नहीं
      • यही सिद्धांत boxplot, density plot जैसे ज्यादा complex layer types पर भी लागू होता है
    • यह उन ज्यादातर visualization tools से अलग है जो पहले पूरा data materialize करते हैं, फिर calculation और plotting करते हैं

  • SELECT pod_door FROM bay WHERE closed

    • यह साबित हो चुका है कि LLM natural language को SQL में बदलने में बहुत प्रभावी हैं
    • यही स्तर ggsql पर भी लागू हो सकेगा, ऐसी उम्मीद जताई गई है
    • querychat में ggsql के जरिए natural language आधारित visual data exploration पहले से संभव है
    • ggsql, R या Python की तुलना में ज्यादा safe और lightweight runtime है, इसलिए production environment में coding agents deploy करने के लिए ज्यादा भरोसा देता है

  • We are now wise beyond our years

    • ggplot2 के 18 साल के development और maintenance का मतलब है data visualization grammar, usability, और design पर 18 साल की संचित सोच
    • यह सारा ज्ञान फिर से पूरा का पूरा ggplot2 में वापस नहीं डाला जा सकता
      • पुराने निर्णयों और user expectations का सम्मान करना पड़ता है, और बदलाव हों भी तो बहुत धीरे-धीरे
    • ggsql एक blank slate है
      • शुरुआत से नया बनाया गया project
      • ऐसे environment के लिए डिज़ाइन किया गया system जहाँ visualization tools को लेकर पहले से बनी expectations नहीं हैं
    • बताया गया है कि इस शुरुआती स्थिति ने development process में आज़ादी और ऊर्जा दी, और वही user experience में भी दिखाई देती है

भविष्य

  • मौजूदा version alpha-release है और अभी पूरा नहीं हुआ है
  • आगे जो चीजें जोड़ने की योजना है, उनकी एक non-exhaustive list दी गई है
    • Rust में शुरू से लिखा गया नया high-performance writer
    • theme infrastructure
    • interactivity
    • Posit Workbench या Positron से Connect तक end-to-end deployment flow
    • पूरा ggsql language server और code formatter
    • spatial data support

  • ggplot2 development के लिए इसका क्या मतलब है

    • कहा गया है कि ggplot2 users ggsql की घोषणा को उत्साह और चिंता दोनों के साथ देख सकते हैं
    • क्या Posit, ggplot2 को पीछे छोड़कर ggsql पर ध्यान दे रहा है? जवाब है नहीं
    • ggplot2 पहले से बहुत mature और stable है, लेकिन इसे support और expand करना जारी रहेगा
    • उम्मीद जताई गई है कि ggsql के development process से ggplot2 में नए features लाने में भी मदद मिलेगी

और जानें

  • अगर आप ggsql को तुरंत आज़माना चाहते हैं, तो ggsql website के Getting started section में installation guide और tutorial देख सकते हैं
  • documentation pages में ggsql की सभी supported capabilities देखी जा सकती हैं
  • user experience पर feedback की उम्मीद का भी उल्लेख है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-04-21
Hacker News की राय

  • हो सकता है मैंने लेख जल्दी-जल्दी देखा हो, लेकिन ब्लॉग पोस्ट और दस्तावेज़ों से SQL डेटाबेस के साथ संबंध मुझे स्पष्ट रूप से समझाया हुआ नहीं लगा
    शुरुआत में मैंने सोचा था कि यह बस एक SQL-जैसी visualization DSL है, जिसे frontend chart library संभालती है
    anatomy दस्तावेज़ पढ़कर ऐसा लगा, लेकिन FAQ के "Can I use SQL queries inside the VISUALISE clause" में लिखा था कि कुछ syntax सीधे डेटाबेस को भेजा जाता है
    homepage पर "ggsql interfaces directly with your database" लिखा है, लेकिन वास्तव में यह कैसे connect होता है यह साफ़ नहीं दिखा, इसलिए भ्रम हुआ

    • मुझे लगता है यह बात वाजिब है. यह अवधारणा खुद भी थोड़ी असामान्य संरचना वाली है
      ggsql सीधे database backend से connect कर सकता है, और चाहें तो in-memory DuckDB पर भी चल सकता है
      visualization query को visualization की हर layer के लिए SQL query में बदला जाता है, और उन result tables का उपयोग rendering में होता है
      उदाहरण के लिए VISUALISE page_views AS x FROM visits DRAW smooth जैसी query data पर smoothing kernel की गणना करने वाली SQL में बदल जाती है, और लौटे हुए points से अंतिम line chart बनाया जाता है
    • ggsql में reader नाम की एक अवधारणा है, और यही SQL डेटाबेस से जुड़ने वाला interface है
      reader database connection और हर DB के अनुरूप SQL dialect generation संभालता है
      अभी alpha चरण में यह duckdb, sqlite, और experimental ODBC reader तक support करता है, और development मुख्य रूप से local file आधारित DuckDB पर केंद्रित है
      मुख्य विचार यह है कि visualization query को कई SQL queries में बदलकर डेटाबेस में चलाया जाए, और लौटे हुए छोटे result set से chart बनाया जाए
      इसलिए बहुत अधिक rows होने पर भी histogram के लिए ज़रूरी statistics SQL में निकाले जा सकते हैं, और bar heights बनाने के लिए सिर्फ कुछ points वापस लाने पड़ते हैं
      default रूप से in-memory DuckDB connection होता है, और CLI में --reader से disk file या ODBC URI से connect किया जा सकता है
      Positron में इसे "Connections" pane से और आसान बनाया जा सकता है, और ggsql Jupyter kernel में magic SQL comment से reader तय किया जा सकता है
      दस्तावेज़ों में ऐसे external tool integration की व्याख्या और मजबूत करने की योजना है
    • मेरे मन में भी यही सवाल था. अगर कोई उदाहरण हो जो external database server से graph बनाने के लिए wiring और dependency का पूरा flow दिखाए, तो समझना बहुत आसान हो जाएगा
    • मेरी नज़र में SQL और database एक ही चीज़ नहीं हैं
      SQL एक declarative data manipulation language है, और डेटाबेस query करने में अक्सर उपयोग होती है, लेकिन सिर्फ डेटाबेस तक सीमित नहीं है
      flat files, data streams, और program memory के अंदर मौजूद data पर भी SQL लागू हो सकता है
      और इसके उलट, database को SQL के बिना भी query किया जा सकता है

  • लेख देखते समय मैं यह समझने की कोशिश कर रहा था कि इसकी ज़रूरत क्यों है और यह कौन-सी समस्या हल करता है, लेकिन बात स्पष्ट नहीं हुई
    लगा कि शायद इसका उद्देश्य remote SQL database की tables को सीधे visualize करना है, ताकि पहले data को R data frame में खींचकर फिर ggplot चलाने का चरण हटाया जा सके
    लेकिन फिर यह सवाल भी था कि एक नई SQL-जैसी भाषा बनाने की ज़रूरत क्यों है
    R में पहले से dbplyr है, जो R और SQL के बीच translation करता है, तो क्या ggplot को dbplyr tbl objects का direct support देकर SQL generate करने तक बढ़ाना ज़्यादा सीधा रास्ता नहीं होता?
    या फिर SQL खुद इतनी परिचित भाषा है कि बहुत से लोग इसी syntax में ggplot-शैली का काम करना चाहेंगे?
    लगभग पूरा documentation पढ़ने के बाद ही मुझे समझ आया कि यह DuckDB और SQLite backends वाला एक standalone visualization app है, जो अभी Vegalite से render करता है और आगे और backends व renderers जोड़ने की योजना रखता है
    नीचे की टिप्पणी की तरह, यह शायद SQL-केंद्रित users के लिए visualization बनाने का tool है जो Python या R नहीं जानते

    • मुझे यह announcement काफ़ी दिलचस्प लगा, इसलिए शायद मैं अपने नज़रिए से बता सकता हूँ कि इसमें आकर्षण क्यों है
      हाँ, मैं भी सहमत हूँ कि घोषणा पोस्ट में यह बात और बेहतर तरह से समझाई जा सकती थी
      मेरे अनुभव में analyst, scientist, और engineer के बीच साझा भाषा अक्सर आख़िरकार SQL ही निकलती है
      R से भी वही काम किया जा सकता है, लेकिन वास्तविक projects हमेशा R या Python में लिखे हुए नहीं होते; जबकि SQL databases और access engines अक्सर पहले से मौजूद होते हैं
      मैं marimo notebook में background DuckDB के साथ अक्सर SQL cells इस्तेमाल करता हूँ, और वहाँ SQL से सीधे plotting मिल जाए तो बहुत सुविधाजनक होगा
      और आख़िर में, Python plotting APIs को याद रखना और सहज बना लेना मुझे हमेशा काफ़ी मुश्किल लगा है
      matplotlib में एक साधारण scatterplot बनाने के लिए भी बहुत boilerplate चाहिए होता है, इसलिए उसी query language के भीतर एकीकृत syntax होना अच्छा लगेगा
    • यह ggplot के बारे में नहीं, बल्कि SQL-शैली syntax और Grammar of Graphics को जोड़ने की कोशिश है
      असली दिलचस्पी किसी खास library से ज़्यादा SQL as interface और GoG की औपचारिकता के संयोजन में है
      वास्तविक renderer या runtime महत्वपूर्ण तो हैं, लेकिन वे ज़्यादा implementation detail जैसे लगते हैं
    • मुझे यह Python या R न जानने वाले SQL users के लिए बना tool लगा
    • SQL से सीधे chart बनाने वाली एक declarative language होने के स्पष्ट लाभ हैं
      हाँ, लगभग उतनी ही पंक्तियों के code में R या Python, matplotlib से भी ऐसी चीज़ें की जा सकती हैं
      लेकिन ऐसे environment को malicious input के खिलाफ सुरक्षित तरीके से sandbox करना कठिन होता है, जबकि ऐसी declarative language को ऐसे host करना आसान होगा जहाँ अविश्वसनीय user ggsql input दें और बदले में सिर्फ chart बने
      इस अर्थ में इसका स्पष्ट उपयोग है
      हालांकि अधिकतर सामान्य उपयोग में, शायद अपनी पसंद के LLM से matplotlib code बनवा लेना आसान विकल्प होगा

  • मैं परियोजना का समर्थन करता हूँ, और इस बात से पूरी तरह सहमत हूँ कि यह अवधारणा SQL में बहुत अच्छी तरह फिट बैठती है
    R में WITH से data तैयार करके उसके बाद VISUALIZE लगाने की संरचना मेरे plotting code जैसी ही लगती है
    लेकिन एक साधारण DSL होने के लाभ से आगे बढ़कर, अभी भी मुझे साफ़ नहीं है कि एक और DSL बनाने की लागत उठाने लायक ggplot2 पर इसका लाभ क्या है
    visualization के कारण मैं ggplot2 को छोड़ने के बारे में लगभग तभी सोचता हूँ जब standard geoms से बाहर की non-standard visualizations बनानी हों, क्योंकि वहाँ यह काफ़ी कठिन हो जाता है
    जब थोड़ा अलग कुछ बनाना हो, तो ggplot-अनुकूल adapter को जबरन बनाने से बेहतर कई बार सीधे नीचे के primitive drawing स्तर पर उतर जाना आसान होता है
    आम इस्तेमाल वाले partial specifications को function में wrap करना भी हमेशा सहज नहीं लगता, चाहे वे + से compose हों या |> या पुराने %>% जैसे pipes से जुड़े हों

    • हमारा लक्ष्य किसी को ggplot2 से हटाना नहीं है
      और ggplot2 का development रोकने का भी कोई इरादा नहीं है
      ggsql आंशिक रूप से ऐसी परियोजना है जो नए users तक पहुँचना चाहती है और शक्तिशाली visualization को नए संदर्भों में रखना चाहती है
      अगर कोई अपना अधिकतर समय R में बिताता है, तो संभव है वह इसका मुख्य target user न हो
      फिर भी इसमें ggplot2 में न मिलने वाली कुछ काफ़ी दिलचस्प चीज़ें हैं, इसलिए खोजबीन मज़ेदार हो सकती है
    • वैसे, |> और %>% एक ही operator नहीं हैं
      अपेक्षाकृत नया base pipe |> तेज़ है, लेकिन %>% के dot placeholder जैसी सुविधा नहीं देता, जहाँ value को function के पहले argument के अलावा किसी और जगह देना हो
      इसलिए कुछ मामलों में %>% अभिव्यक्ति को थोड़ा अधिक साफ़ बना देता है

  • यह सच में बहुत अच्छा लगा
    हमने भी GFQL नाम की एक graph dataframe query language बनाते समय लगभग ऐसा ही निष्कर्ष निकाला था
    खासकर visualization और analytics stack के लिए हमें code sandbox के बिना उपयोग होने वाला LLM-friendly interface चाहिए था
    हमने देखा कि केवल बुनियादी opencypher extensions से भी काफी समृद्ध GPU visual analytics pipeline बनाई जा सकती है, और इसी वजह से tabular दुनिया में SQL की ओर जाना भी बहुत उचित लगता है
    GFQL की ओर से उदाहरण के लिए data loading, shape transformation, algorithm-based enrichment, visual encoding, और first-class pipelines पर overall pipelines और सरल call pattern वाले declarative visual encodings देखे जा सकते हैं

  • यह काफ़ी अच्छा लग रहा है
    बस लगा कि ऐसा कोई तरीका होना चाहिए जिससे syntax support न होने वाले environment में भी यह gracefully degrade कर सके
    मैंने भी कभी इसी दिशा में, लेकिन GoG की तुलना में बहुत सरल SQL-अंदरूनी तरीका बनाया था, और उसमें degrade संभव था
    syntax पढ़ने में बहुत सुंदर नहीं था, लेकिन sqlnb spec जैसी चीज़ थी

    • "degrade in context" से आपका ठीक-ठीक क्या मतलब है, यह लेकर मैं थोड़ा उलझ गया
      हो सके तो थोड़ा और ठोस उदाहरण दें

  • इसी तरह के tools में DuckDB आधारित Shaper भी याद आता है
    यह पूरे dashboard को SQL-first तरीके से संभालने का दृष्टिकोण है, और getting started दस्तावेज़ देखकर दिशा काफ़ी मिलती-जुलती लगती है

  • सबसे पहले तो ggsql सच में शानदार लग रहा है, और मैं इसे जल्दी आज़माना चाहता हूँ
    लेकिन documentation में एक कमी साफ़ दिखी: output formats का विवरण ढूँढना मुश्किल था
    क्या यह PDF दे सकता है, SVG या PNG support हैं या नहीं, और width/height जैसी output controls कैसे काम करती हैं, यह साफ़ नहीं था
    मुझे सबसे नज़दीकी संकेत Python library docs में chart.display() और chart.save("chart.html") के रूप में मिला

    • अभी writer module सिर्फ vegalite-only है, और output vegalite spec वाले JSON के रूप में मिलता है
      इस output को मौजूदा tools के जरिए interactive charts, SVG, PNG आदि में render किया जा सकता है, और size जैसे controls भी उन्हीं tools की settings के अनुसार किए जाते हैं
      ggsql Jupyter kernel इसी vegalite spec का उपयोग करके Quarto documents में charts output कर सकता है
      आगे चलकर हम ऐसा high-performance writer बनाना चाहते हैं जो इस मध्यवर्ती vegalite चरण से न गुज़रे, और तब शायद ऐसे सवालों का अधिक स्पष्ट उत्तर दिया जा सकेगा

  • जानना चाहता था कि निकट या दूर भविष्य में ggplot2 extension packages के साथ integration की कोई योजना है या नहीं
    अगर यह पहले से बताया गया था तो क्षमा चाहता हूँ

    • ggplot2 समुदाय द्वारा बनाए गए अलग-अलग niche geoms को निकट भविष्य में लाना कठिन लगता है
      इस परियोजना का उद्देश्य ggplot2 को replace करना नहीं, बल्कि एक अलग approach देना है
      यह ggplot2 के कई काम कर सकता है, और कुछ ऐसे भी जो ggplot2 नहीं कर पाता, लेकिन मुझे लगता है कि लंबे समय तक कई कामों में ggplot2 अधिक शक्तिशाली रहेगा

  • यह वाकई बहुत शानदार लग रहा है और मैं जल्द इसे आज़माने वाला हूँ
    मेरे लिए सबसे असरदार बात grammar दस्तावेज़ की व्याख्या थी
    पहले से परिचित SELECT से data चुनना, फिर VISUALIZE या VISUALISE से table से plot में बदलना, उसके बाद DRAW से aesthetics map करना, और फिर SCALE, FACET, LABEL को क्रम से जोड़ना — यह पूरा flow SQL की संरचित सोच को ही आगे बढ़ाता हुआ लगा

  • मुझे layering approach सच में बहुत पसंद आई
    जब basic chart से आगे बढ़ना पड़ता है, तब दूसरे SQL visualization hybrid tools में जो समस्याएँ अक्सर आती हैं, यह तरीका उन्हें अच्छी तरह हल करता हुआ लगा