digna CLI संदर्भ 2026.06¶
2026-09-05
यह पृष्ठ digna CLI रिलीज़ 2026.06 में उपलब्ध कमांड के संपूर्ण समूह का दस्तावेज़ीकरण करता है, जिसमें उपयोग के उदाहरण और विकल्प शामिल हैं।
निष्पादन योग्य फ़ाइल का नाम digna है।
CLI की मूल बातें¶
अवलोकन और सिंटैक्स¶
रिलीज़ 2026.06 का CLI एक संरचित, श्रेणी-आधारित कमांड पदानुक्रम का उपयोग करता है:
version और serve उपकमांड रहित एकल कमांड हैं:
वैश्विक विकल्प¶
निम्नलिखित वैश्विक विकल्प सभी कमांड पर लागू होते हैं:
--help,-h: CLI अथवा किसी विशिष्ट कमांड श्रेणी या उपकमांड के लिए सहायता जानकारी प्रदर्शित करता है।--stacktrace: विफलता पर केवल शीर्ष-स्तरीय संदेश के बजाय संपूर्ण त्रुटि शृंखला प्रदर्शित करता है।
--stacktrace कड़े अर्थों में एक वैश्विक विकल्प है: इसे कमांड श्रेणी से पहले देना होता है, उसके बाद नहीं।
कोई --version फ़्लैग नहीं है। इसके बजाय version कमांड का उपयोग करें।
पूर्वापेक्षाएँ¶
अधिकांश कमांड को एक पठनीय, वैध config.toml चाहिए; कुछ को इसके अतिरिक्त वैध लाइसेंस भी चाहिए। निम्नलिखित तालिका दर्ज करती है कि प्रत्येक कमांड श्रेणी कुछ भी करने से पहले क्या लोड करती है:
| कमांड श्रेणी | config.toml आवश्यक है | वैध लाइसेंस आवश्यक है |
|---|---|---|
version | नहीं | नहीं |
config check | नहीं (कमांड इसी पर रिपोर्ट देता है) | नहीं |
license check | नहीं | यही स्वयं जाँच है |
crypt | हाँ | नहीं |
serve | हाँ | नहीं |
windows | नहीं (सेवा प्रारंभ होते समय इसे पढ़ती है) | नहीं |
project | हाँ | नहीं |
user | हाँ | हाँ |
inspection | हाँ | हाँ |
repo | हाँ | हाँ |
जहाँ लाइसेंस आवश्यक है, वहाँ उसके हस्ताक्षर और समाप्ति तिथि दोनों की जाँच होती है, और यदि इनमें से कोई भी विफल हो तो कमांड रिपॉज़िटरी को छुए बिना ही रुक जाता है।
निकास कोड¶
0: कमांड सफल रहा।1: कमांड विफल रहा। त्रुटि संदेशError:उपसर्ग के साथ stderr पर लिखा जाता है।
help¶
--help विकल्प उपलब्ध कमांड श्रेणियों, उपकमांड और विकल्पों के बारे में जानकारी देता है:
-
सामान्य सहायता प्रदर्शित करना:
-
विशिष्ट श्रेणियों और कमांड के लिए सहायता प्राप्त करना:
आउटपुट में शामिल है: - कमांड विवरण: कमांड के उद्देश्य का सारांश। - सिंटैक्स: आवश्यक और वैकल्पिक आर्ग्युमेंट। - विकल्प: कमांड-विशिष्ट फ़्लैग और पैरामीटर।
version¶
version कमांड स्थापित digna रिलीज़ को प्रिंट करता है। यह कोई कॉन्फ़िगरेशन नहीं पढ़ता और न ही किसी लाइसेंस को सत्यापित करता है, इसलिए यह ऐसी स्थापना पर भी काम करता है जिसकी config.toml या लाइसेंस अनुपस्थित अथवा अमान्य हो।
रिलीज़ संस्करण उस रिपॉज़िटरी स्कीमा संस्करण से स्वतंत्र है जिसकी सूचना repo check देता है।
कमांड उपयोग¶
उदाहरण आउटपुट¶
कॉन्फ़िगरेशन प्रबंधन¶
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 को प्रारंभ ही न होने दे।
कमांड उपयोग¶
विकल्प¶
--configpath,-c: कॉन्फ़िगरेशन फ़ाइल का पथ, अथवाconfig.tomlवाली निर्देशिका का पथ (डिफ़ॉल्ट./config.toml)।--json: सत्यापन रिपोर्ट को JSON के रूप में आउटपुट करता है।--quietपर वरीयता रखता है।--quiet,-q: रिपोर्ट को दबा देता है और केवल निकास कोड पर निर्भर रहता है।
उदाहरण¶
किसी विशिष्ट कॉन्फ़िगरेशन फ़ाइल को सत्यापित करें और आउटपुट को 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 रिलीज़ से अलग होता है।
कमांड उपयोग¶
उदाहरण आउटपुट¶
repo install¶
repo install कमांड config.toml में कॉन्फ़िगर किए गए स्कीमा में एक नई digna रिपॉज़िटरी स्थापित करता है और सभी आवश्यक अनुक्रम, तालिकाएँ, अनुक्रमणिकाएँ, बाध्यताएँ तथा प्रारंभिक रिकॉर्ड बनाता है।
स्कीमा स्वयं इस कमांड द्वारा नहीं बनाया जाता — वह पहले से मौजूद होना चाहिए। यदि उस स्कीमा में पहले से कोई रिपॉज़िटरी स्थापित है तो कमांड चलने से इनकार कर देता है, और यदि स्थापित संस्करण पुराना है तो repo upgrade की ओर संकेत करता है।
कमांड उपयोग¶
उदाहरण आउटपुट¶
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 कमांड डेटाबेस स्कीमा माइग्रेशन लागू करता है ताकि मौजूदा रिपॉज़िटरी को उस संस्करण तक लाया जा सके जिसकी स्थापित रिलीज़ अपेक्षा करती है। अपग्रेड एक निश्चित अपग्रेड पथ पर एक समय में एक संस्करण-चरण के रूप में लागू होते हैं, और प्रत्येक पूर्ण चरण रिपॉज़िटरी में दर्ज किया जाता है।
यदि रिपॉज़िटरी पहले से ही अपेक्षित संस्करण पर है, तो कमांड सूचित करता है कि किसी अपग्रेड की आवश्यकता नहीं है और कोई परिवर्तन नहीं करता।
कमांड उपयोग¶
उदाहरण आउटपुट¶
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 बैकएंड द्वारा उन तालिकाओं में लिखी गई पंक्तियाँ, जिनका वर्तमान रिलीज़ अब उपयोग नहीं करती, अछूती छोड़ दी जाती हैं।
कमांड उपयोग¶
विकल्प¶
--dry-run: कुछ भी हटाए बिना बताता है कि क्या हटाया जाएगा।
केवल अनाथ (orphaned) पंक्तियों वाली तालिकाएँ सूचीबद्ध की जाती हैं। यदि कोई नहीं है, तो कमांड No orphaned rows found. बताता है और समाप्त हो जाता है।
उदाहरण¶
उदाहरण आउटपुट¶
"check" 29342
check_profile 29342
check_prediction 29342
check_status 29342
column_status 32
inspection_query 253
---------------------------------------------
total 117854
✅ Removed 117854 orphaned row(s).
कुछ भी हटाए बिना वही रिपोर्ट देखने के लिए:
पंक्ति-गणनाएँ समान रहती हैं; केवल अंतिम पंक्ति भिन्न होती है:
एन्क्रिप्शन प्रबंधन¶
crypt gen-key¶
crypt gen-key कमांड एक नई AES-GCM एन्क्रिप्शन कुंजी उत्पन्न करता है, जिसका उपयोग config.toml में एन्क्रिप्शन कुंजी के रूप में किया जाता है। लोड की जा सकने वाली config.toml पहले से मौजूद होनी चाहिए, भले ही उत्पन्न कुंजी उस पर निर्भर न हो।
कमांड उपयोग¶
उदाहरण आउटपुट¶
crypt encrypt¶
crypt encrypt कमांड config.toml में कॉन्फ़िगर की गई AES-GCM कुंजी का उपयोग करके किसी स्ट्रिंग (जैसे डेटाबेस पासवर्ड) को एन्क्रिप्ट करता है और सिफरटेक्स्ट प्रिंट करता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- VALUE: एन्क्रिप्ट की जाने वाली सादा-पाठ स्ट्रिंग (आवश्यक)।
उदाहरण¶
crypt decrypt¶
crypt decrypt कमांड config.toml में कॉन्फ़िगर की गई कुंजी का उपयोग करके AES-GCM से एन्क्रिप्ट की गई स्ट्रिंग को डिक्रिप्ट करता है और सादा पाठ प्रिंट करता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- VALUE: डिक्रिप्ट की जाने वाली एन्क्रिप्टेड सिफरटेक्स्ट स्ट्रिंग (आवश्यक)।
उदाहरण¶
उपयोगकर्ता प्रबंधन¶
user add¶
user add कमांड digna रिपॉज़िटरी में एक नया उपयोगकर्ता खाता बनाता है। यदि दिए गए ईमेल पते वाला उपयोगकर्ता पहले से मौजूद है तो कमांड विफल हो जाता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- EMAIL: उपयोगकर्ता का ईमेल पता (आवश्यक)।
- PASSWORD: उपयोगकर्ता का प्रारंभिक पासवर्ड (आवश्यक)।
- DISPLAY_NAME: उपयोगकर्ता का पूरा प्रदर्शित नाम (आवश्यक)।
विकल्प¶
--admin,-a: उपयोगकर्ता को प्रशासक (सुपरयूज़र) विशेषाधिकारों के साथ बनाता है।
उदाहरण¶
प्रशासक खाता बनाने के लिए:
उदाहरण आउटपुट¶
user list¶
user list कमांड सभी पंजीकृत उपयोगकर्ताओं को तालिका रूप में ID, ईमेल, प्रदर्शित नाम और प्रशासक ध्वज सहित सूचीबद्ध करता है।
कमांड उपयोग¶
उदाहरण आउटपुट¶
ID EMAIL DISPLAY NAME ADMIN
-----------------------------------------------------------------------------------------------
42 jdoe@example.com John Doe false
43 admin@example.com Admin User true
user modify¶
user modify कमांड ईमेल पते से पहचाने गए किसी मौजूदा उपयोगकर्ता खाते के प्रदर्शित नाम और प्रशासक विशेषाधिकारों को अद्यतन करता है।
प्रदर्शित नाम और प्रशासक ध्वज दोनों हमेशा लिखे जाते हैं। --admin एक स्विच है, मान नहीं: इसे छोड़ देने पर प्रशासक विशेषाधिकार वापस ले लिए जाते हैं, इसलिए जब भी उपयोगकर्ता को ये बनाए रखने हों या प्राप्त करने हों, इसे अवश्य दें।
कमांड उपयोग¶
आर्ग्युमेंट¶
- EMAIL: संशोधित किए जाने वाले उपयोगकर्ता का ईमेल (आवश्यक)।
- DISPLAY_NAME: अद्यतन प्रदर्शित नाम (आवश्यक)।
विकल्प¶
--admin,-a: प्रशासक विशेषाधिकार प्रदान करता है। इन्हें वापस लेने के लिए इसे छोड़ दें।--valid-until,-v: संगतता के लिए स्वीकार किया जाता है परंतु वर्तमान में लागू नहीं होता। इसे देने पर चेतावनी प्रिंट होती है और कुछ नहीं बदलता।
उदाहरण¶
उदाहरण आउटपुट¶
user modify-pwd¶
user modify-pwd कमांड किसी मौजूदा उपयोगकर्ता खाते का पासवर्ड अद्यतन करता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- EMAIL: उस उपयोगकर्ता का ईमेल जिसका पासवर्ड अद्यतन किया जाना है (आवश्यक)।
- PASSWORD: नया पासवर्ड (आवश्यक)।
उदाहरण¶
user delete¶
user delete कमांड सिस्टम से किसी उपयोगकर्ता खाते को हटा देता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- EMAIL: हटाए जाने वाले उपयोगकर्ता का ईमेल (आवश्यक)।
उदाहरण¶
प्रोजेक्ट और डेटा स्रोत प्रबंधन¶
project list¶
project list कमांड रिपॉज़िटरी में उपलब्ध सभी प्रोजेक्ट को उनकी ID, नाम और विवरण सहित सूचीबद्ध करता है।
कमांड उपयोग¶
उदाहरण आउटपुट¶
ID NAME DESCRIPTION
------------------------------------------------------------------------------------------------------
7 ProjectA Sales data quality
8 ProjectB Finance data quality
project list-ds¶
project list-ds कमांड किसी दिए गए प्रोजेक्ट से संबद्ध सभी डेटा स्रोतों को उनकी ID, नाम, प्रकार, स्कीमा और तालिका नाम सहित सूचीबद्ध करता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- PROJECT_NAME: उस प्रोजेक्ट का नाम जिसके डेटा स्रोत सूचीबद्ध किए जाने हैं (आवश्यक)। नाम बिल्कुल मेल खाना चाहिए।
उदाहरण¶
उदाहरण आउटपुट¶
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 दिया गया हो, तो प्रोजेक्ट के सभी डेटा स्रोत निर्यात किए जाते हैं।
कमांड उपयोग¶
आर्ग्युमेंट¶
- PROJECT_NAME: उस प्रोजेक्ट का नाम जिससे डेटा स्रोत निर्यात किए जाने हैं (आवश्यक)।
विकल्प¶
--table-name,-n: निर्यात किए जाने वाले डेटा स्रोतों के नाम। रिक्त स्थान से पृथक करके अनेक नाम दिए जा सकते हैं।--table-id,-i: निर्यात किए जाने वाले डेटा स्रोतों की ID। रिक्त स्थान से पृथक करके अनेक ID दी जा सकती हैं।--exportfile,-f: वह पथ जहाँ निर्यात किए गए डेटा स्रोत सहेजे जाते हैं (डिफ़ॉल्ट:data_sources_export.json)।
उदाहरण¶
ProjectA से सभी डेटा स्रोत निर्यात करने के लिए:
विशिष्ट तालिकाएँ निर्यात करने के लिए:
उदाहरण आउटपुट¶
project import-ds¶
project import-ds कमांड किसी निर्यात फ़ाइल से डेटा स्रोतों को लक्ष्य प्रोजेक्ट में आयात करता है और प्रति ऑब्जेक्ट सूचित करता है कि क्या बनाया गया, क्या अद्यतन हुआ अथवा क्या छोड़ा गया।
कमांड उपयोग¶
आर्ग्युमेंट¶
- PROJECT_NAME: वह लक्ष्य प्रोजेक्ट नाम जिसमें आयात करना है (आवश्यक)।
- EXPORT_FILE: JSON निर्यात फ़ाइल का पथ (आवश्यक)।
विकल्प¶
--output-file,-o: वह फ़ाइल जिसमें आयात रिपोर्ट लिखी जाती है। इसके बिना रिपोर्ट stdout पर जाती है।--output-format,-f: आयात रिपोर्ट का प्रारूप —table,jsonअथवाcsv(डिफ़ॉल्ट:table)।
उदाहरण¶
मशीन-पठनीय रिपोर्ट प्राप्त करने के लिए:
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 लेता है, और प्रत्येक नियोजित ऑब्जेक्ट के लिए एक चरण संख्या जोड़ता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- PROJECT_NAME: लक्ष्य प्रोजेक्ट का नाम (आवश्यक)।
- EXPORT_FILE: निर्यात फ़ाइल का पथ (आवश्यक)।
विकल्प¶
--output-file,-o: वह फ़ाइल जिसमें आयात योजना लिखी जाती है। इसके बिना योजना stdout पर जाती है।--output-format,-f: आयात योजना का प्रारूप —table,jsonअथवाcsv(डिफ़ॉल्ट:table)।
उदाहरण¶
project cleanup¶
project cleanup कमांड किसी प्रोजेक्ट द्वारा एक तिथि-सीमा में संचित निरीक्षण परिणामों को हटाता है — प्रोफ़ाइल, पूर्वानुमान, पंक्ति-गणनाएँ और प्रत्येक चेक, एट्रिब्यूट, डेटासेट और डेटा स्रोत की स्थिति। यह ठीक वही हटाता है जो उन तिथियों के निरीक्षण ने लिखा था, इसलिए बाद में उस सीमा का फिर से निरीक्षण करके उसे पुनर्निर्मित किया जा सकता है।
Timeliness और Schema Tracker का इतिहास नहीं हटाया जाता: वे दर्ज करते हैं कि digna ने किसी दिन क्या देखा, न कि उससे निकाला गया कोई परिणाम, इसलिए किसी पिछली तिथि-सीमा की सफ़ाई उन्हें अक्षुण्ण छोड़ देती है।
प्रत्येक डेटा स्रोत अपने स्वयं के ट्रांज़ैक्शन में साफ़ किया जाता है, इसलिए बाधित रन पूरे डेटा स्रोत छोड़ता है, न कि आधा साफ़ किया हुआ कोई डेटा स्रोत।
कमांड उपयोग¶
आर्ग्युमेंट¶
- 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 के रूप में संयोजित होते हैं — कोई डेटा स्रोत तब साफ़ किया जाता है जब उसका नाम दिया गया हो या सबस्ट्रिंग मेल खाती हो। यदि कोई भी डेटा स्रोत मेल नहीं खाता, तो कमांड विफल हो जाता है, बजाय इसके कि वह ऐसी सफ़ाई को सफल बताए जिसने कुछ नहीं किया।
उदाहरण¶
एक डेटा स्रोत तक सीमित:
उदाहरण आउटपुट¶
Cleaning up project 'ProjectA' from 2026-01-01 to 2026-06-30:
- Table1
- Table2
- Table3
✅ Cleaned up 3 data source(s).
कुछ भी हटाए बिना यह देखने के लिए कि कौन-से डेटा स्रोत साफ़ किए जाएँगे:
हर पंक्ति चिह्नित होती है, इसलिए ड्राई रन को वास्तविक रन समझने की भूल नहीं हो सकती:
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 परस्पर अनन्य हैं।
प्रत्येक विधि में, यदि निरीक्षण सफलतापूर्वक पूर्ण नहीं हुआ तो कमांड शून्येतर निकास कोड के साथ समाप्त होता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- PROJECT_NAME: लक्ष्य प्रोजेक्ट का नाम (आवश्यक)। नाम बिल्कुल मेल खाना चाहिए।
- START_DATE: तिथि-सीमा की आरंभ तिथि
YYYY-MM-DDप्रारूप में (आवश्यक)। - END_DATE: तिथि-सीमा की अंतिम तिथि
YYYY-MM-DDप्रारूप में (आवश्यक)।
विकल्प¶
--table-name: निरीक्षण को प्रोजेक्ट के एकल डेटा स्रोत तक सीमित करता है, जिसे डेटा स्रोत नाम से दिया जाता है। इसके बिना प्रोजेक्ट के सभी डेटा स्रोतों का निरीक्षण होता है।--async-mode: निरीक्षण को कतार में रखता है और उसकी प्रतीक्षा करने के बजाय अनुरोध ID प्रिंट करता है। इसे--bypass-backendके साथ नहीं जोड़ा जा सकता।--bypass-backend: निरीक्षण को बैकएंड की कतार में रखने के बजाय सीधे CLI प्रक्रिया में चलाता है। इसे--async-modeके साथ नहीं जोड़ा जा सकता।
उदाहरण¶
अतुल्यकालिक निरीक्षण प्रस्तुत करने के लिए:
एकल डेटा स्रोत का निरीक्षण करने के लिए:
उदाहरण आउटपुट¶
डिफ़ॉल्ट विधि:
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 status¶
inspection status कमांड किसी निरीक्षण अनुरोध की स्थिति और कार्य प्रगति को उसकी अनुरोध ID के आधार पर पूछता है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- INSPECTION_REQUEST_ID: निरीक्षण अनुरोध की संख्यात्मक ID (आवश्यक)।
उदाहरण¶
उदाहरण आउटपुट¶
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 कमांड चल रहे अथवा लंबित निरीक्षण अनुरोधों को रद्द करने का अनुरोध करता है। यह प्रत्येक प्रभावित अनुरोध के लिए एक स्टॉप घटना दर्ज करता है; बैकएंड उस पर कार्रवाई करता है, इसलिए निरस्तीकरण तत्काल समाप्ति न होकर रुकने का अनुरोध है।
कमांड उपयोग¶
आर्ग्युमेंट¶
- INSPECTION_REQUEST_ID: निरस्त किए जाने वाले निरीक्षण अनुरोध की ID। जब तक
--killallन दिया जाए, यह आवश्यक है।
विकल्प¶
--killall: वर्तमान में चल रहे और लंबित सभी निरीक्षण अनुरोधों को निरस्त करता है। साथ में दी गई अनुरोध ID पर वरीयता रखता है।
उदाहरण¶
किसी विशिष्ट अनुरोध को निरस्त करने के लिए:
सभी सक्रिय और कतारबद्ध निरीक्षणों को निरस्त करने के लिए:
उदाहरण आउटपुट¶
--killall बताता है कि उसने क्या किया; एकल अनुरोध को निरस्त करने पर कोई आउटपुट नहीं आता और सफलता की सूचना उसके निकास कोड से मिलती है।
लाइसेंस प्रबंधन¶
license check¶
license check कमांड license.toml को सत्यापित करता है, स्थापना के साथ आए सार्वजनिक कुंजी के विरुद्ध उसके हस्ताक्षर की पुष्टि करता है और जाँचता है कि वह समाप्त तो नहीं हुआ। यह कोई एप्लिकेशन कॉन्फ़िगरेशन नहीं पढ़ता, इसलिए config.toml सेट होने से पहले भी काम करता है।
कमांड उपयोग¶
उदाहरण आउटपुट¶
अमान्य हस्ताक्षर और समाप्त लाइसेंस को अलग-अलग त्रुटियों के रूप में सूचित किया जाता है, दोनों निकास कोड 1 के साथ।
सर्वर और पृष्ठभूमि सेवाएँ¶
serve¶
serve कमांड digna REST API सर्वर को पृष्ठभूमि निरीक्षण अनुसूचक और निरीक्षण प्रबंधक के साथ प्रारंभ करता है। प्रारंभ होते समय यह उन सभी निरीक्षणों को भी विफल कर देता है जिन्हें रिपॉज़िटरी अब भी चालू के रूप में दर्ज रखती है, क्योंकि किसी पूर्ववर्ती प्रक्रिया से कुछ भी शेष नहीं रह सकता।
कमांड तब तक अग्रभूमि में चलता है जब तक उसे रोका न जाए।
कमांड उपयोग¶
विकल्प¶
--address: वह नेटवर्क पता जिससे API सर्वर को बाँधा जाता है (डिफ़ॉल्ट:127.0.0.1)।--port: वह पोर्ट संख्या जिस पर सुना जाता है (डिफ़ॉल्ट:8000)।
उदाहरण¶
उदाहरण आउटपुट¶
Windows सेवा प्रबंधन¶
केवल Windows पर उपलब्ध। ये कमांड digna बैकएंड को Windows सेवा प्रबंधक के साथ रजिस्टर करते हैं और उसे नियंत्रित करते हैं; सेवा स्वयं पृष्ठभूमि में serve चलाती है। प्रत्येक कमांड को उन्नत (elevated) Command Prompt से चलाना आवश्यक है, और प्रत्येक --name स्वीकार करता है ताकि गैर-डिफ़ॉल्ट नाम से रजिस्टर की गई सेवा को संबोधित किया जा सके।
windows install¶
windows install कमांड digna को Windows सेवा के रूप में रजिस्टर करता है।
यहाँ दिए गए पता और पोर्ट सेवा रजिस्ट्रेशन में दर्ज होते हैं और सेवा इन्हीं से बाँधी जाती है — इन्हें config.toml से नहीं पढ़ा जाता। बाद में इन्हें बदलने के लिए सेवा को अनइंस्टॉल करें और फिर से इंस्टॉल करें।
कमांड उपयोग¶
विकल्प¶
--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वाली डायरेक्टरी, जिसे सेवा अपनी वर्किंग डायरेक्टरी बनाती है (डिफ़ॉल्ट:dignaexecutable की डायरेक्टरी)।--start-type: सेवा कब प्रारंभ होती है —autoWindows के साथ,manualकेवल कहने पर,disabledरजिस्टर तो होती है पर प्रारंभ होने से मना करती है (डिफ़ॉल्ट:auto)।--account: वह खाता जिसके रूप में चलाना है, उदा.DOMAIN\userया.\user(डिफ़ॉल्ट:LocalSystem)।--password:--accountका पासवर्ड।
उदाहरण¶
दूसरे नाम से, डोमेन खाते के रूप में चलने वाली सेवा रजिस्टर करें:
digna windows install --name digna-test --display-name "digna (test)" --account DOMAIN\svc_digna --password <password>
windows start¶
windows start कमांड किसी रजिस्टर की गई सेवा को प्रारंभ करता है।
कमांड उपयोग¶
विकल्प¶
--name: वह नाम जिससे सेवा रजिस्टर है (डिफ़ॉल्ट:digna)।
windows stop¶
windows stop कमांड चल रही सेवा को रोकता है। किसी भी एप्लिकेशन फ़ाइल को बदलने से पहले सेवा को रोकें।
कमांड उपयोग¶
विकल्प¶
--name: वह नाम जिससे सेवा रजिस्टर है (डिफ़ॉल्ट:digna)।
windows uninstall¶
windows uninstall कमांड सेवा को अनरजिस्टर करता है। पहले इसे रोकें।
कमांड उपयोग¶
विकल्प¶
--name: वह नाम जिससे सेवा रजिस्टर है (डिफ़ॉल्ट:digna)।