SQLite में (Rust-शैली) editions होने चाहिए

मूल लेख ↗ Hacker News चर्चा ↗

SQLite की लंबे समय से चली आ रही backward compatibility आधुनिक safer defaults की अपेक्षाओं से टकरा रही है, जिससे Rust-शैली के “edition” mechanism की माँग उठ रही है, जो पुराने databases को तोड़े बिना नए databases को stricter behavior में opt in करे। टिप्पणीकार इस पर बहस कर रहे हैं कि क्या `PRAGMA edition=2026` जैसा एक switch—foreign keys enforcement, strict typing, busy timeouts, और WAL mode जैसी चीज़ों के लिए—वाकई reliability बढ़ाएगा या सिर्फ configuration trade-offs को धुंधला करेगा, खासकर जब SQLite एक portable on-disk format की तरह भी काम करता है। दूसरे लोग argue करते हैं कि wrapper libraries, compile-time flags, या DuckDB और Firebird जैसे alternative embedded databases बेहतर guarantees दे सकते हैं, जबकि SQLite की minimalism और tiny footprint बने रहें।

Editions की अवधारणा और लक्ष्य

  • कई टिप्पणीकारों को एक “edition” या “compatibility level” pragma का विचार पसंद है, जो आधुनिक defaults का एक सेट (जैसे stricter typing, FK enforcement, busy timeout, WAL) एक साथ जोड़ दे, बिना पुराने code को तोड़े।
  • Editions को SQLite की 20 साल पुरानी defaults से आगे बढ़ने का opt‑in तरीका माना जा रहा है, जबकि backward-compatibility का वादा बना रहे।
  • तुलना Rust editions, C++ “epochs/profiles”, CMake policies, Postfix compatibility_level, और JS use strict से की जा रही है।

Backwards compatibility और portability

  • SQLite एक data container है जिसे अक्सर machines और tools के बीच ले जाया जाता है; पुराने /usr/bin/sqlite3 binaries अक्सर नई embedded versions से बनी files पढ़ लेते हैं।
  • आलोचकों को चिंता है कि editions से ये समस्याएँ आ सकती हैं:
    • Underlying pragmas और edition mappings दोनों को समझना पड़ेगा।
    • अगर edition N बाद में जोड़ी गई features पर निर्भर हो, तो बीच के SQLite versions बाहर हो सकते हैं।
    • सख्त semantics सक्षम होने पर मौजूदा data को संभालना जटिल हो सकता है।
  • समर्थकों का जवाब है कि ये आज individual pragmas के साथ मौजूद issues से ज़्यादा अलग नहीं हैं, और वे प्रस्ताव रखते हैं:
    • Editions को केवल connection-level macros बनाना (file में store न करना)।
    • Strict one-way rules और self-describing metadata बनाए रखना।

Defaults: FKs, typing, busy timeout, WAL

  • कई लोग मानते हैं कि मौजूदा defaults (FK enforcement नहीं, loose typing, busy timeout नहीं, rollback journal) सामान्य “app database” उपयोग के लिए खराब हैं और अक्सर override किए जाते हैं।
  • दूसरे लोग status quo का बचाव करते हैं:
    • Embedded/low-resource environments minimalism और loose typing को पसंद कर सकते हैं।
    • busy_timeout स्वभाव से application-specific है; 5s बनाम 1s बनाम 60s चुनना मनमाना है।
    • WAL एक अलग format है, हर जगह supported नहीं है, और corruption के लिए ज़्यादा जोखिमपूर्ण माना जाता है।

Typing, STRICT tables, और data quality

  • कई टिप्पणीकार SQLite के type system को “dangerous” मानते हैं और default के रूप में strict typing चाहते हैं।
  • दूसरे तर्क देते हैं कि loose typing गंदी CSV/legacy data ingest करने में बेहद उपयोगी है, जहाँ invalid dates, numbers, आदि आम हैं।
  • STRICT tables को एक उपयोगी कदम माना जाता है, लेकिन complete validation solution नहीं; गंभीर validation अक्सर higher layer पर ही करनी पड़ती है।

SQLite का scope और alternatives

  • SQLite को full client-server, अत्यधिक concurrent system बनाने के खिलाफ ज़ोरदार विरोध है; कुछ लोग कहते हैं कि अगर वही चाहिए तो “use Postgres” या अन्य embedded engines (DuckDB, Firebird) इस्तेमाल करें।
  • प्रतिवाद: local app database में भी safer defaults होने चाहिए; editions या feature-sets legacy behavior बदले बिना यह दे सकते हैं।

Implementation और ecosystem concerns

  • चिंताओं में हर अतिरिक्त edition के लिए code bloat, testing surface का बढ़ना, और भ्रम (“edition 2026” क्या enabled है इसे छुपा देता है) शामिल हैं।
  • सुझाए गए mitigation: editions को existing pragmas के ऊपर tiny macros की तरह implement करना; संभव हो तो limited set रखना, या year-based editions की जगह feature-sets इस्तेमाल करना।
  • कुछ ORM और wrapper ecosystems नई SQLite features (जैसे STRICT) को धीरे अपनाते हैं, जिससे tooling के catch up करने तक व्यावहारिक लाभ सीमित रह सकता है।