विषय पर बढ़ें

digna CLI संदर्भ 2026.06

2026-09-05

यह पृष्ठ digna CLI रिलीज़ 2026.06 में उपलब्ध कमांड के संपूर्ण समूह का दस्तावेज़ीकरण करता है, जिसमें उपयोग के उदाहरण और विकल्प शामिल हैं।

निष्पादन योग्य फ़ाइल का नाम digna है।


CLI की मूल बातें


अवलोकन और सिंटैक्स

रिलीज़ 2026.06 का CLI एक संरचित, श्रेणी-आधारित कमांड पदानुक्रम का उपयोग करता है:

digna [GLOBAL_OPTIONS] <COMMAND_CATEGORY> <SUBCOMMAND> [OPTIONS] [ARGUMENTS]

version और serve उपकमांड रहित एकल कमांड हैं:

digna [GLOBAL_OPTIONS] <COMMAND> [OPTIONS] [ARGUMENTS]

वैश्विक विकल्प

निम्नलिखित वैश्विक विकल्प सभी कमांड पर लागू होते हैं:

  • --help, -h: CLI अथवा किसी विशिष्ट कमांड श्रेणी या उपकमांड के लिए सहायता जानकारी प्रदर्शित करता है।
  • --stacktrace: विफलता पर केवल शीर्ष-स्तरीय संदेश के बजाय संपूर्ण त्रुटि शृंखला प्रदर्शित करता है।

--stacktrace कड़े अर्थों में एक वैश्विक विकल्प है: इसे कमांड श्रेणी से पहले देना होता है, उसके बाद नहीं।

digna --stacktrace repo check     # correct
digna repo check --stacktrace     # rejected: unknown argument

कोई --version फ़्लैग नहीं है। इसके बजाय version कमांड का उपयोग करें।

पूर्वापेक्षाएँ

अधिकांश कमांड को एक पठनीय, वैध config.toml चाहिए; कुछ को इसके अतिरिक्त वैध लाइसेंस भी चाहिए। निम्नलिखित तालिका दर्ज करती है कि प्रत्येक कमांड श्रेणी कुछ भी करने से पहले क्या लोड करती है:

कमांड श्रेणी config.toml आवश्यक है वैध लाइसेंस आवश्यक है
version नहीं नहीं
config check नहीं (कमांड इसी पर रिपोर्ट देता है) नहीं
license check नहीं यही स्वयं जाँच है
crypt हाँ नहीं
serve हाँ नहीं
windows नहीं (सेवा प्रारंभ होते समय इसे पढ़ती है) नहीं
project हाँ नहीं
user हाँ हाँ
inspection हाँ हाँ
repo हाँ हाँ

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

निकास कोड

  • 0: कमांड सफल रहा।
  • 1: कमांड विफल रहा। त्रुटि संदेश Error: उपसर्ग के साथ stderr पर लिखा जाता है।

help

--help विकल्प उपलब्ध कमांड श्रेणियों, उपकमांड और विकल्पों के बारे में जानकारी देता है:

  1. सामान्य सहायता प्रदर्शित करना:

    digna --help
    

  2. विशिष्ट श्रेणियों और कमांड के लिए सहायता प्राप्त करना:

    digna user --help
    digna user add --help
    

आउटपुट में शामिल है: - कमांड विवरण: कमांड के उद्देश्य का सारांश। - सिंटैक्स: आवश्यक और वैकल्पिक आर्ग्युमेंट। - विकल्प: कमांड-विशिष्ट फ़्लैग और पैरामीटर।

version

version कमांड स्थापित digna रिलीज़ को प्रिंट करता है। यह कोई कॉन्फ़िगरेशन नहीं पढ़ता और न ही किसी लाइसेंस को सत्यापित करता है, इसलिए यह ऐसी स्थापना पर भी काम करता है जिसकी config.toml या लाइसेंस अनुपस्थित अथवा अमान्य हो।

रिलीज़ संस्करण उस रिपॉज़िटरी स्कीमा संस्करण से स्वतंत्र है जिसकी सूचना repo check देता है।

कमांड उपयोग

digna version

उदाहरण आउटपुट

2026.06

कॉन्फ़िगरेशन प्रबंधन


config check

config check कमांड कॉन्फ़िगरेशन फ़ाइल (config.toml) को सत्यापित करता है और यह जाँचता है कि सभी अनिवार्य अनुभाग और सेटिंग्स मौजूद तथा ठीक से स्वरूपित हैं। प्रत्येक अनुभाग की जाँच अलग से होती है, इसलिए क्षतिग्रस्त [app] अनुभाग [repo] की स्थिति को नहीं छिपाता।

रिपोर्ट किए जाने वाले अनुभाग हैं:

  • App config ([app])
  • Repository config ([repo])
  • Base config ([base])
  • Logging config ([logging])
  • Encryption config ([encryption])
  • OIDC config(s) (oidc_clients) — वैकल्पिक; अनुपस्थित कुंजी जाँच में उत्तीर्ण होती है, जबकि उपस्थित परंतु त्रुटिपूर्ण सूची विफल हो जाती है

यह कमांड जानबूझकर एप्लिकेशन कॉन्फ़िगरेशन को उस तरह लोड नहीं करता जैसे अन्य कमांड करते हैं, ताकि यह ऐसी config.toml का निदान कर सके जो digna को प्रारंभ ही न होने दे।

कमांड उपयोग

digna config check [OPTIONS]

विकल्प

  • --configpath, -c: कॉन्फ़िगरेशन फ़ाइल का पथ, अथवा config.toml वाली निर्देशिका का पथ (डिफ़ॉल्ट ./config.toml)।
  • --json: सत्यापन रिपोर्ट को JSON के रूप में आउटपुट करता है। --quiet पर वरीयता रखता है।
  • --quiet, -q: रिपोर्ट को दबा देता है और केवल निकास कोड पर निर्भर रहता है।

उदाहरण

digna config check

किसी विशिष्ट कॉन्फ़िगरेशन फ़ाइल को सत्यापित करें और आउटपुट को JSON के रूप में स्वरूपित करें:

digna config check --configpath /etc/digna/config.toml --json

उदाहरण आउटपुट

Configuration validation report (source: config.toml):
 - App config: OK
 - Repository config: OK
 - Base config: OK
 - Logging config: OK
 - Encryption config: FAILED
    missing field `aes_gcm_key`
 - OIDC config(s): OK

Overall: FAILED

अनुपस्थित फ़ाइल अथवा TOML सिंटैक्स त्रुटि की स्थिति में अनुभाग-दर-अनुभाग सत्यापित करने योग्य कुछ नहीं बचता, और --quiet या --json के बावजूद इसे रिपोर्ट के बजाय एकल त्रुटि के रूप में सूचित किया जाता है।


रिपॉज़िटरी प्रबंधन


repo check

repo check कमांड डेटाबेस कनेक्शन का परीक्षण करता है तथा रिपॉज़िटरी की स्थापना और संस्करण की पुष्टि करता है। यदि कॉन्फ़िगर किया गया स्कीमा मौजूद नहीं है, या मौजूद तो है परंतु उसमें कोई digna रिपॉज़िटरी नहीं है, तो यह विफल हो जाता है।

रिपोर्ट किया गया संस्करण रिपॉज़िटरी स्कीमा का संस्करण है, जिसका संस्करणकरण version द्वारा प्रिंट की जाने वाली digna रिलीज़ से अलग होता है।

कमांड उपयोग

digna repo check

उदाहरण आउटपुट

Repo version 3.0.0 installed

repo install

repo install कमांड config.toml में कॉन्फ़िगर किए गए स्कीमा में एक नई digna रिपॉज़िटरी स्थापित करता है और सभी आवश्यक अनुक्रम, तालिकाएँ, अनुक्रमणिकाएँ, बाध्यताएँ तथा प्रारंभिक रिकॉर्ड बनाता है।

स्कीमा स्वयं इस कमांड द्वारा नहीं बनाया जाता — वह पहले से मौजूद होना चाहिए। यदि उस स्कीमा में पहले से कोई रिपॉज़िटरी स्थापित है तो कमांड चलने से इनकार कर देता है, और यदि स्थापित संस्करण पुराना है तो repo upgrade की ओर संकेत करता है।

कमांड उपयोग

digna repo install

उदाहरण आउटपुट

Installing repo version 3.0.0
✅ Sequences created.
✅ Tables and Indices created.
✅ Constraints created.
✅ Records inserted.
✅ Repo version 3.0.0 successfully installed.

repo upgrade

repo upgrade कमांड डेटाबेस स्कीमा माइग्रेशन लागू करता है ताकि मौजूदा रिपॉज़िटरी को उस संस्करण तक लाया जा सके जिसकी स्थापित रिलीज़ अपेक्षा करती है। अपग्रेड एक निश्चित अपग्रेड पथ पर एक समय में एक संस्करण-चरण के रूप में लागू होते हैं, और प्रत्येक पूर्ण चरण रिपॉज़िटरी में दर्ज किया जाता है।

यदि रिपॉज़िटरी पहले से ही अपेक्षित संस्करण पर है, तो कमांड सूचित करता है कि किसी अपग्रेड की आवश्यकता नहीं है और कोई परिवर्तन नहीं करता।

कमांड उपयोग

digna repo upgrade

उदाहरण आउटपुट

Upgrading from 2.3.1 to 2.3.2...
Upgrading from 2.3.2 to 3.0.0...
✅ Repo successfully upgraded to version 3.0.0.

repo prune

repo prune कमांड उन पंक्तियों को हटाता है जो उस प्रोजेक्ट या डेटा स्रोत के बाद भी बनी रहीं जिससे वे संबंधित थीं। किसी प्रोजेक्ट या डेटा स्रोत को हटाने से स्वयं वह ऑब्जेक्ट हट जाता है, पर उसकी प्रोफ़ाइल, पूर्वानुमान, स्थितियाँ और पंक्ति-गणनाएँ पीछे रह जाती हैं — यह एक सोचा-समझा समझौता है, क्योंकि जो हटाना उन तालिकाओं को भी साफ़ करे वह उपयोगकर्ता को प्रतीक्षा में रखेगा। repo prune वह रखरखाव चरण है जो उन्हें साफ़ करता है, और इसे किसी भी समय चलाना सुरक्षित है: यह केवल वही पंक्तियाँ हटाता है जिनका प्रोजेक्ट या डेटा स्रोत अब मौजूद नहीं है।

Python बैकएंड द्वारा उन तालिकाओं में लिखी गई पंक्तियाँ, जिनका वर्तमान रिलीज़ अब उपयोग नहीं करती, अछूती छोड़ दी जाती हैं।

कमांड उपयोग

digna repo prune [OPTIONS]

विकल्प

  • --dry-run: कुछ भी हटाए बिना बताता है कि क्या हटाया जाएगा।

केवल अनाथ (orphaned) पंक्तियों वाली तालिकाएँ सूचीबद्ध की जाती हैं। यदि कोई नहीं है, तो कमांड No orphaned rows found. बताता है और समाप्त हो जाता है।

उदाहरण

digna repo prune

उदाहरण आउटपुट

"check"                                 29342
check_profile                           29342
check_prediction                        29342
check_status                            29342
column_status                              32
inspection_query                          253
---------------------------------------------
total                                  117854

✅ Removed 117854 orphaned row(s).

कुछ भी हटाए बिना वही रिपोर्ट देखने के लिए:

digna repo prune --dry-run

पंक्ति-गणनाएँ समान रहती हैं; केवल अंतिम पंक्ति भिन्न होती है:

---------------------------------------------
total                                  117854

Dry run - nothing was removed.


एन्क्रिप्शन प्रबंधन


crypt gen-key

crypt gen-key कमांड एक नई AES-GCM एन्क्रिप्शन कुंजी उत्पन्न करता है, जिसका उपयोग config.toml में एन्क्रिप्शन कुंजी के रूप में किया जाता है। लोड की जा सकने वाली config.toml पहले से मौजूद होनी चाहिए, भले ही उत्पन्न कुंजी उस पर निर्भर न हो।

कमांड उपयोग

digna crypt gen-key

उदाहरण आउटपुट

Encryption key: <base64-encoded key>

crypt encrypt

crypt encrypt कमांड config.toml में कॉन्फ़िगर की गई AES-GCM कुंजी का उपयोग करके किसी स्ट्रिंग (जैसे डेटाबेस पासवर्ड) को एन्क्रिप्ट करता है और सिफरटेक्स्ट प्रिंट करता है।

कमांड उपयोग

digna crypt encrypt <VALUE>

आर्ग्युमेंट

  • VALUE: एन्क्रिप्ट की जाने वाली सादा-पाठ स्ट्रिंग (आवश्यक)।

उदाहरण

digna crypt encrypt mysecretpassword

crypt decrypt

crypt decrypt कमांड config.toml में कॉन्फ़िगर की गई कुंजी का उपयोग करके AES-GCM से एन्क्रिप्ट की गई स्ट्रिंग को डिक्रिप्ट करता है और सादा पाठ प्रिंट करता है।

कमांड उपयोग

digna crypt decrypt <VALUE>

आर्ग्युमेंट

  • VALUE: डिक्रिप्ट की जाने वाली एन्क्रिप्टेड सिफरटेक्स्ट स्ट्रिंग (आवश्यक)।

उदाहरण

digna crypt decrypt "encrypted_string_here"

उपयोगकर्ता प्रबंधन


user add

user add कमांड digna रिपॉज़िटरी में एक नया उपयोगकर्ता खाता बनाता है। यदि दिए गए ईमेल पते वाला उपयोगकर्ता पहले से मौजूद है तो कमांड विफल हो जाता है।

कमांड उपयोग

digna user add <EMAIL> <PASSWORD> <DISPLAY_NAME> [OPTIONS]

आर्ग्युमेंट

  • EMAIL: उपयोगकर्ता का ईमेल पता (आवश्यक)।
  • PASSWORD: उपयोगकर्ता का प्रारंभिक पासवर्ड (आवश्यक)।
  • DISPLAY_NAME: उपयोगकर्ता का पूरा प्रदर्शित नाम (आवश्यक)।

विकल्प

  • --admin, -a: उपयोगकर्ता को प्रशासक (सुपरयूज़र) विशेषाधिकारों के साथ बनाता है।

उदाहरण

digna user add jdoe@example.com "SecurePass123!" "John Doe"

प्रशासक खाता बनाने के लिए:

digna user add admin@example.com "AdminPass123!" "Admin User" --admin

उदाहरण आउटपुट

User created with ID: 42

user list

user list कमांड सभी पंजीकृत उपयोगकर्ताओं को तालिका रूप में ID, ईमेल, प्रदर्शित नाम और प्रशासक ध्वज सहित सूचीबद्ध करता है।

कमांड उपयोग

digna user list

उदाहरण आउटपुट

ID                   EMAIL                          DISPLAY NAME                   ADMIN
-----------------------------------------------------------------------------------------------
42                   jdoe@example.com               John Doe                       false
43                   admin@example.com              Admin User                     true

user modify

user modify कमांड ईमेल पते से पहचाने गए किसी मौजूदा उपयोगकर्ता खाते के प्रदर्शित नाम और प्रशासक विशेषाधिकारों को अद्यतन करता है।

प्रदर्शित नाम और प्रशासक ध्वज दोनों हमेशा लिखे जाते हैं। --admin एक स्विच है, मान नहीं: इसे छोड़ देने पर प्रशासक विशेषाधिकार वापस ले लिए जाते हैं, इसलिए जब भी उपयोगकर्ता को ये बनाए रखने हों या प्राप्त करने हों, इसे अवश्य दें।

कमांड उपयोग

digna user modify <EMAIL> <DISPLAY_NAME> [OPTIONS]

आर्ग्युमेंट

  • EMAIL: संशोधित किए जाने वाले उपयोगकर्ता का ईमेल (आवश्यक)।
  • DISPLAY_NAME: अद्यतन प्रदर्शित नाम (आवश्यक)।

विकल्प

  • --admin, -a: प्रशासक विशेषाधिकार प्रदान करता है। इन्हें वापस लेने के लिए इसे छोड़ दें।
  • --valid-until, -v: संगतता के लिए स्वीकार किया जाता है परंतु वर्तमान में लागू नहीं होता। इसे देने पर चेतावनी प्रिंट होती है और कुछ नहीं बदलता।

उदाहरण

digna user modify jdoe@example.com "Johnathan Doe" --admin

उदाहरण आउटपुट

User jdoe@example.com modified successfully

user modify-pwd

user modify-pwd कमांड किसी मौजूदा उपयोगकर्ता खाते का पासवर्ड अद्यतन करता है।

कमांड उपयोग

digna user modify-pwd <EMAIL> <PASSWORD>

आर्ग्युमेंट

  • EMAIL: उस उपयोगकर्ता का ईमेल जिसका पासवर्ड अद्यतन किया जाना है (आवश्यक)।
  • PASSWORD: नया पासवर्ड (आवश्यक)।

उदाहरण

digna user modify-pwd jdoe@example.com "NewSecurePass456!"

user delete

user delete कमांड सिस्टम से किसी उपयोगकर्ता खाते को हटा देता है।

कमांड उपयोग

digna user delete <EMAIL>

आर्ग्युमेंट

  • EMAIL: हटाए जाने वाले उपयोगकर्ता का ईमेल (आवश्यक)।

उदाहरण

digna user delete jdoe@example.com

प्रोजेक्ट और डेटा स्रोत प्रबंधन


project list

project list कमांड रिपॉज़िटरी में उपलब्ध सभी प्रोजेक्ट को उनकी ID, नाम और विवरण सहित सूचीबद्ध करता है।

कमांड उपयोग

digna project list

उदाहरण आउटपुट

ID                   NAME                           DESCRIPTION
------------------------------------------------------------------------------------------------------
7                    ProjectA                       Sales data quality
8                    ProjectB                       Finance data quality

project list-ds

project list-ds कमांड किसी दिए गए प्रोजेक्ट से संबद्ध सभी डेटा स्रोतों को उनकी ID, नाम, प्रकार, स्कीमा और तालिका नाम सहित सूचीबद्ध करता है।

कमांड उपयोग

digna project list-ds <PROJECT_NAME>

आर्ग्युमेंट

  • PROJECT_NAME: उस प्रोजेक्ट का नाम जिसके डेटा स्रोत सूचीबद्ध किए जाने हैं (आवश्यक)। नाम बिल्कुल मेल खाना चाहिए।

उदाहरण

digna project list-ds ProjectA

उदाहरण आउटपुट

ID                   NAME                           KIND            SCHEMA               TABLE
-------------------------------------------------------------------------------------------------------------
101                  orders                         Table           sales                orders
102                  customers                      Table           sales                customers

project export-ds

project export-ds कमांड किसी प्रोजेक्ट के डेटा स्रोतों को JSON दस्तावेज़ में निर्यात करता है।

यदि न तो --table-name और न ही --table-id दिया गया हो, तो प्रोजेक्ट के सभी डेटा स्रोत निर्यात किए जाते हैं।

कमांड उपयोग

digna project export-ds <PROJECT_NAME> [OPTIONS]

आर्ग्युमेंट

  • PROJECT_NAME: उस प्रोजेक्ट का नाम जिससे डेटा स्रोत निर्यात किए जाने हैं (आवश्यक)।

विकल्प

  • --table-name, -n: निर्यात किए जाने वाले डेटा स्रोतों के नाम। रिक्त स्थान से पृथक करके अनेक नाम दिए जा सकते हैं।
  • --table-id, -i: निर्यात किए जाने वाले डेटा स्रोतों की ID। रिक्त स्थान से पृथक करके अनेक ID दी जा सकती हैं।
  • --exportfile, -f: वह पथ जहाँ निर्यात किए गए डेटा स्रोत सहेजे जाते हैं (डिफ़ॉल्ट: data_sources_export.json)।

उदाहरण

ProjectA से सभी डेटा स्रोत निर्यात करने के लिए:

digna project export-ds ProjectA --exportfile my_export.json

विशिष्ट तालिकाएँ निर्यात करने के लिए:

digna project export-ds ProjectA --table-name users orders -f users_orders_export.json

उदाहरण आउटपुट

Successfully exported 2 data source(s) to users_orders_export.json

project import-ds

project import-ds कमांड किसी निर्यात फ़ाइल से डेटा स्रोतों को लक्ष्य प्रोजेक्ट में आयात करता है और प्रति ऑब्जेक्ट सूचित करता है कि क्या बनाया गया, क्या अद्यतन हुआ अथवा क्या छोड़ा गया।

कमांड उपयोग

digna project import-ds <PROJECT_NAME> <EXPORT_FILE> [OPTIONS]

आर्ग्युमेंट

  • PROJECT_NAME: वह लक्ष्य प्रोजेक्ट नाम जिसमें आयात करना है (आवश्यक)।
  • EXPORT_FILE: JSON निर्यात फ़ाइल का पथ (आवश्यक)।

विकल्प

  • --output-file, -o: वह फ़ाइल जिसमें आयात रिपोर्ट लिखी जाती है। इसके बिना रिपोर्ट stdout पर जाती है।
  • --output-format, -f: आयात रिपोर्ट का प्रारूप — table, json अथवा csv (डिफ़ॉल्ट: table)।

उदाहरण

digna project import-ds ProjectB my_export.json

मशीन-पठनीय रिपोर्ट प्राप्त करने के लिए:

digna project import-ds ProjectB my_export.json --output-format json --output-file import_report.json

रिपोर्ट चार ऑब्जेक्ट स्तरों को समाहित करती है — डेटा स्रोत, डेटा सेट परिभाषा, विशेषता और सत्यापन नियम — प्रत्येक के साथ उसकी आयात क्रिया, परिणाम, परिणामी ऑब्जेक्ट ID और कोई अतिरिक्त जानकारी।

project plan-import-ds

project plan-import-ds कमांड किसी लक्ष्य प्रोजेक्ट में डेटा स्रोत आयात का पूर्वावलोकन दिखाता है और बताता है कि कौन-से ऑब्जेक्ट बनाए जाएँगे, अद्यतन होंगे अथवा छोड़े जाएँगे, बिना कुछ बदले। यह वही निर्यात फ़ाइल तथा वही रिपोर्टिंग विकल्प लेता है जो project import-ds लेता है, और प्रत्येक नियोजित ऑब्जेक्ट के लिए एक चरण संख्या जोड़ता है।

कमांड उपयोग

digna project plan-import-ds <PROJECT_NAME> <EXPORT_FILE> [OPTIONS]

आर्ग्युमेंट

  • PROJECT_NAME: लक्ष्य प्रोजेक्ट का नाम (आवश्यक)।
  • EXPORT_FILE: निर्यात फ़ाइल का पथ (आवश्यक)।

विकल्प

  • --output-file, -o: वह फ़ाइल जिसमें आयात योजना लिखी जाती है। इसके बिना योजना stdout पर जाती है।
  • --output-format, -f: आयात योजना का प्रारूप — table, json अथवा csv (डिफ़ॉल्ट: table)।

उदाहरण

digna project plan-import-ds ProjectB my_export.json

project cleanup

project cleanup कमांड किसी प्रोजेक्ट द्वारा एक तिथि-सीमा में संचित निरीक्षण परिणामों को हटाता है — प्रोफ़ाइल, पूर्वानुमान, पंक्ति-गणनाएँ और प्रत्येक चेक, एट्रिब्यूट, डेटासेट और डेटा स्रोत की स्थिति। यह ठीक वही हटाता है जो उन तिथियों के निरीक्षण ने लिखा था, इसलिए बाद में उस सीमा का फिर से निरीक्षण करके उसे पुनर्निर्मित किया जा सकता है।

Timeliness और Schema Tracker का इतिहास नहीं हटाया जाता: वे दर्ज करते हैं कि digna ने किसी दिन क्या देखा, न कि उससे निकाला गया कोई परिणाम, इसलिए किसी पिछली तिथि-सीमा की सफ़ाई उन्हें अक्षुण्ण छोड़ देती है।

प्रत्येक डेटा स्रोत अपने स्वयं के ट्रांज़ैक्शन में साफ़ किया जाता है, इसलिए बाधित रन पूरे डेटा स्रोत छोड़ता है, न कि आधा साफ़ किया हुआ कोई डेटा स्रोत।

कमांड उपयोग

digna project cleanup <PROJECT_NAME> <FROM_DATE> <TO_DATE> [OPTIONS]

आर्ग्युमेंट

  • PROJECT_NAME: साफ़ किया जाने वाला प्रोजेक्ट (आवश्यक)। प्रति कमांड एक प्रोजेक्ट।
  • FROM_DATE: वह पहली तिथि जिसके परिणाम हटाने हैं, YYYY-MM-DD (आवश्यक)।
  • TO_DATE: वह अंतिम तिथि जिसके परिणाम हटाने हैं, सम्मिलित, YYYY-MM-DD (आवश्यक)।

विकल्प

  • --table-name, -n: सफ़ाई को इन डेटा स्रोतों तक सीमित करता है। रिक्त स्थान से पृथक करके अनेक नाम दिए जा सकते हैं।
  • --table-filter: सफ़ाई को उन डेटा स्रोतों तक सीमित करता है जिनके नाम में यह सबस्ट्रिंग है।
  • --dry-run: कुछ भी हटाए बिना उन डेटा स्रोतों की सूची देता है जो साफ़ किए जाएँगे।
  • --timing: दिखाता है कि सफ़ाई में कितना समय लगा।

--table-name और --table-filter OR के रूप में संयोजित होते हैं — कोई डेटा स्रोत तब साफ़ किया जाता है जब उसका नाम दिया गया हो या सबस्ट्रिंग मेल खाती हो। यदि कोई भी डेटा स्रोत मेल नहीं खाता, तो कमांड विफल हो जाता है, बजाय इसके कि वह ऐसी सफ़ाई को सफल बताए जिसने कुछ नहीं किया।

उदाहरण

digna project cleanup ProjectA 2026-01-01 2026-06-30

एक डेटा स्रोत तक सीमित:

digna project cleanup ProjectA 2026-01-01 2026-06-30 --table-name Table1

उदाहरण आउटपुट

Cleaning up project 'ProjectA' from 2026-01-01 to 2026-06-30:
- Table1
- Table2
- Table3

✅ Cleaned up 3 data source(s).

कुछ भी हटाए बिना यह देखने के लिए कि कौन-से डेटा स्रोत साफ़ किए जाएँगे:

digna project cleanup ProjectA 2026-01-01 2026-06-30 --dry-run

हर पंक्ति चिह्नित होती है, इसलिए ड्राई रन को वास्तविक रन समझने की भूल नहीं हो सकती:

Cleaning up project 'ProjectA' from 2026-01-01 to 2026-06-30:
- Table1 (dry run, nothing removed)
- Table2 (dry run, nothing removed)
- Table3 (dry run, nothing removed)

Dry run - 3 data source(s) would be cleaned up.


निरीक्षण प्रबंधन


inspection run

inspection run कमांड किसी प्रोजेक्ट और तिथि-सीमा के लिए निरीक्षण अनुरोध बनाता है और फिर — दिए गए विकल्पों के अनुसार — या तो उसकी प्रतीक्षा करता है, या तुरंत लौट आता है, या उसे अपनी ही प्रक्रिया में चलाता है।

तीन निष्पादन विधियाँ हैं:

  • डिफ़ॉल्ट (कोई फ़्लैग नहीं): अनुरोध बैकएंड के लिए कतार में रखा जाता है, और CLI हर दो सेकंड में उसकी स्थिति पूछता है तथा कार्य प्रगति प्रिंट करता है, जब तक निरीक्षण अंतिम स्थिति तक न पहुँच जाए। चालू digna serve आवश्यक है, अन्यथा अनुरोध को कोई नहीं उठाता।
  • --async-mode: अनुरोध कतार में रखा जाता है और उसकी ID तुरंत प्रिंट कर दी जाती है। इसका अनुसरण करने के लिए inspection status का उपयोग करें।
  • --bypass-backend: निरीक्षण स्वयं CLI प्रक्रिया द्वारा निष्पादित होता है और कतार में नहीं रखा जाता, इसलिए किसी चालू सर्वर की आवश्यकता नहीं होती।

--async-mode और --bypass-backend परस्पर अनन्य हैं।

प्रत्येक विधि में, यदि निरीक्षण सफलतापूर्वक पूर्ण नहीं हुआ तो कमांड शून्येतर निकास कोड के साथ समाप्त होता है।

कमांड उपयोग

digna inspection run <PROJECT_NAME> <START_DATE> <END_DATE> [OPTIONS]

आर्ग्युमेंट

  • PROJECT_NAME: लक्ष्य प्रोजेक्ट का नाम (आवश्यक)। नाम बिल्कुल मेल खाना चाहिए।
  • START_DATE: तिथि-सीमा की आरंभ तिथि YYYY-MM-DD प्रारूप में (आवश्यक)।
  • END_DATE: तिथि-सीमा की अंतिम तिथि YYYY-MM-DD प्रारूप में (आवश्यक)।

विकल्प

  • --table-name: निरीक्षण को प्रोजेक्ट के एकल डेटा स्रोत तक सीमित करता है, जिसे डेटा स्रोत नाम से दिया जाता है। इसके बिना प्रोजेक्ट के सभी डेटा स्रोतों का निरीक्षण होता है।
  • --async-mode: निरीक्षण को कतार में रखता है और उसकी प्रतीक्षा करने के बजाय अनुरोध ID प्रिंट करता है। इसे --bypass-backend के साथ नहीं जोड़ा जा सकता।
  • --bypass-backend: निरीक्षण को बैकएंड की कतार में रखने के बजाय सीधे CLI प्रक्रिया में चलाता है। इसे --async-mode के साथ नहीं जोड़ा जा सकता।

उदाहरण

digna inspection run ProjectA 2024-01-01 2024-01-31

अतुल्यकालिक निरीक्षण प्रस्तुत करने के लिए:

digna inspection run ProjectA 2024-01-01 2024-01-31 --async-mode

एकल डेटा स्रोत का निरीक्षण करने के लिए:

digna inspection run ProjectA 2024-01-01 2024-01-31 --table-name orders

उदाहरण आउटपुट

डिफ़ॉल्ट विधि:

Inspection request submitted. Waiting for completion (Request ID: 1024)...
Progress: 3/10 tasks completed (0 failed)
Progress: 10/10 tasks completed (0 failed)
Inspection completed successfully.
Inspection successful for project: ProjectA

अतुल्यकालिक विधि:

Inspection request submitted successfully. Request ID: 1024

inspection status

inspection status कमांड किसी निरीक्षण अनुरोध की स्थिति और कार्य प्रगति को उसकी अनुरोध ID के आधार पर पूछता है।

कमांड उपयोग

digna inspection status <INSPECTION_REQUEST_ID>

आर्ग्युमेंट

  • INSPECTION_REQUEST_ID: निरीक्षण अनुरोध की संख्यात्मक ID (आवश्यक)।

उदाहरण

digna inspection status 1024

उदाहरण आउटपुट

Inspection Request ID: 1024
Status: Running
Project ID: 7
Date Range: 2024-01-01 to 2024-01-31
Progress: 3/10 tasks completed (0 failed)

inspection abort

inspection abort कमांड चल रहे अथवा लंबित निरीक्षण अनुरोधों को रद्द करने का अनुरोध करता है। यह प्रत्येक प्रभावित अनुरोध के लिए एक स्टॉप घटना दर्ज करता है; बैकएंड उस पर कार्रवाई करता है, इसलिए निरस्तीकरण तत्काल समाप्ति न होकर रुकने का अनुरोध है।

कमांड उपयोग

digna inspection abort [INSPECTION_REQUEST_ID] [OPTIONS]

आर्ग्युमेंट

  • INSPECTION_REQUEST_ID: निरस्त किए जाने वाले निरीक्षण अनुरोध की ID। जब तक --killall न दिया जाए, यह आवश्यक है।

विकल्प

  • --killall: वर्तमान में चल रहे और लंबित सभी निरीक्षण अनुरोधों को निरस्त करता है। साथ में दी गई अनुरोध ID पर वरीयता रखता है।

उदाहरण

किसी विशिष्ट अनुरोध को निरस्त करने के लिए:

digna inspection abort 1024

सभी सक्रिय और कतारबद्ध निरीक्षणों को निरस्त करने के लिए:

digna inspection abort --killall

उदाहरण आउटपुट

--killall बताता है कि उसने क्या किया; एकल अनुरोध को निरस्त करने पर कोई आउटपुट नहीं आता और सफलता की सूचना उसके निकास कोड से मिलती है।

All running and pending inspections have been aborted.


लाइसेंस प्रबंधन


license check

license check कमांड license.toml को सत्यापित करता है, स्थापना के साथ आए सार्वजनिक कुंजी के विरुद्ध उसके हस्ताक्षर की पुष्टि करता है और जाँचता है कि वह समाप्त तो नहीं हुआ। यह कोई एप्लिकेशन कॉन्फ़िगरेशन नहीं पढ़ता, इसलिए config.toml सेट होने से पहले भी काम करता है।

कमांड उपयोग

digna license check

उदाहरण आउटपुट

License is valid

अमान्य हस्ताक्षर और समाप्त लाइसेंस को अलग-अलग त्रुटियों के रूप में सूचित किया जाता है, दोनों निकास कोड 1 के साथ।


सर्वर और पृष्ठभूमि सेवाएँ


serve

serve कमांड digna REST API सर्वर को पृष्ठभूमि निरीक्षण अनुसूचक और निरीक्षण प्रबंधक के साथ प्रारंभ करता है। प्रारंभ होते समय यह उन सभी निरीक्षणों को भी विफल कर देता है जिन्हें रिपॉज़िटरी अब भी चालू के रूप में दर्ज रखती है, क्योंकि किसी पूर्ववर्ती प्रक्रिया से कुछ भी शेष नहीं रह सकता।

कमांड तब तक अग्रभूमि में चलता है जब तक उसे रोका न जाए।

कमांड उपयोग

digna serve [OPTIONS]

विकल्प

  • --address: वह नेटवर्क पता जिससे API सर्वर को बाँधा जाता है (डिफ़ॉल्ट: 127.0.0.1)।
  • --port: वह पोर्ट संख्या जिस पर सुना जाता है (डिफ़ॉल्ट: 8000)।

उदाहरण

digna serve --address 0.0.0.0 --port 8000

उदाहरण आउटपुट

Server running on http://0.0.0.0:8000

Windows सेवा प्रबंधन

केवल Windows पर उपलब्ध। ये कमांड digna बैकएंड को Windows सेवा प्रबंधक के साथ रजिस्टर करते हैं और उसे नियंत्रित करते हैं; सेवा स्वयं पृष्ठभूमि में serve चलाती है। प्रत्येक कमांड को उन्नत (elevated) Command Prompt से चलाना आवश्यक है, और प्रत्येक --name स्वीकार करता है ताकि गैर-डिफ़ॉल्ट नाम से रजिस्टर की गई सेवा को संबोधित किया जा सके।


windows install

windows install कमांड digna को Windows सेवा के रूप में रजिस्टर करता है।

यहाँ दिए गए पता और पोर्ट सेवा रजिस्ट्रेशन में दर्ज होते हैं और सेवा इन्हीं से बाँधी जाती है — इन्हें config.toml से नहीं पढ़ा जाता। बाद में इन्हें बदलने के लिए सेवा को अनइंस्टॉल करें और फिर से इंस्टॉल करें।

कमांड उपयोग

digna windows install [OPTIONS]

विकल्प

  • --name: वह नाम जिससे सेवा रजिस्टर की जाती है (डिफ़ॉल्ट: digna)।
  • --display-name: services.msc में दिखाया जाने वाला नाम (डिफ़ॉल्ट: digna)।
  • --description: services.msc में दिखाया जाने वाला विवरण (डिफ़ॉल्ट: digna data quality backend)।
  • --address: वह पता जिससे सेवा अपने API को बाँधती है (डिफ़ॉल्ट: 127.0.0.1)।
  • --port: वह पोर्ट जिससे सेवा अपने API को बाँधती है (डिफ़ॉल्ट: 8000)।
  • --working-dir: config.toml और license.toml वाली डायरेक्टरी, जिसे सेवा अपनी वर्किंग डायरेक्टरी बनाती है (डिफ़ॉल्ट: digna executable की डायरेक्टरी)।
  • --start-type: सेवा कब प्रारंभ होती है — auto Windows के साथ, manual केवल कहने पर, disabled रजिस्टर तो होती है पर प्रारंभ होने से मना करती है (डिफ़ॉल्ट: auto)।
  • --account: वह खाता जिसके रूप में चलाना है, उदा. DOMAIN\user या .\user (डिफ़ॉल्ट: LocalSystem)।
  • --password: --account का पासवर्ड।

उदाहरण

digna windows install --address 0.0.0.0 --port 8082

दूसरे नाम से, डोमेन खाते के रूप में चलने वाली सेवा रजिस्टर करें:

digna windows install --name digna-test --display-name "digna (test)" --account DOMAIN\svc_digna --password <password>


windows start

windows start कमांड किसी रजिस्टर की गई सेवा को प्रारंभ करता है।

कमांड उपयोग

digna windows start [OPTIONS]

विकल्प

  • --name: वह नाम जिससे सेवा रजिस्टर है (डिफ़ॉल्ट: digna)।

windows stop

windows stop कमांड चल रही सेवा को रोकता है। किसी भी एप्लिकेशन फ़ाइल को बदलने से पहले सेवा को रोकें।

कमांड उपयोग

digna windows stop [OPTIONS]

विकल्प

  • --name: वह नाम जिससे सेवा रजिस्टर है (डिफ़ॉल्ट: digna)।

windows uninstall

windows uninstall कमांड सेवा को अनरजिस्टर करता है। पहले इसे रोकें।

कमांड उपयोग

digna windows uninstall [OPTIONS]

विकल्प

  • --name: वह नाम जिससे सेवा रजिस्टर है (डिफ़ॉल्ट: digna)।