लेबल डेटा स्रोत के रूप में PostgreSQL: एक क्वेरी, हज़ारों लेबल

आर्टिकल मास्टर डेटा PostgreSQL में रहता है और लेबल उसी से निकलने चाहिए। सामान्य रास्ता है CSV एक्सपोर्ट, जो पूरा होते ही पुराना पड़ जाता है। बेहतर रास्ता: डेटाबेस ही स्रोत बना रहता है, और लेबल प्रिंटिंग सीधे उससे क्वेरी करती है।

यहाँ बताई गई हर बात MySQL और MariaDB पर भी लागू होती है - केवल कनेक्शन स्ट्रिंग अलग दिखती है।

डेटाबेस तक दो रास्ते

एजेंट के ज़रिए, जब डेटाबेस आपके अपने नेटवर्क के अंदर हो। zplCloudCli एजेंट प्लेटफ़ॉर्म से एक आउटबाउंड कनेक्शन खोलता है, क्वेरी स्थानीय रूप से चलाता है और केवल परिणाम की पंक्तियाँ वापस भेजता है। कनेक्शन स्ट्रिंग केवल आपकी मशीन पर रहती है। किसी इनबाउंड पोर्ट की ज़रूरत नहीं।

सीधे क्लाउड से, जब डेटाबेस वैसे भी पहुँच योग्य हो - उदाहरण के लिए Azure Database for PostgreSQL या Amazon RDS। तब प्लेटफ़ॉर्म स्वयं कनेक्ट होता है; कनेक्शन स्ट्रिंग प्लेटफ़ॉर्म डेटाबेस में AES-एन्क्रिप्टेड संग्रहीत होती है और केवल क्वेरी चलाने के लिए डिक्रिप्ट की जाती है।

एजेंट वाला रास्ता: सर्वर पंजीकृत करें

एजेंट को अपने डेटाबेस के बारे में एक विकल्प, एक एनवायरनमेंट वेरिएबल या एक फ़ाइल से पता चलता है। तीनों समान रूप से काम करते हैं।

# स्टार्ट-अप विकल्प के रूप में
zplcloud proxy --agent "Warehouse" \
  --postgres WMS="Host=pg.internal.lan;Database=wms;Username=zplcloud;Password=...;SSL Mode=Require"

# या एनवायरनमेंट वेरिएबल के रूप में
export ZPLCLOUD_PG_WMS_CONNECTION="Host=pg.internal.lan;Database=wms;Username=zplcloud;Password=..."
zplcloud proxy --agent "Warehouse"

# या बाइनरी के बगल में या ~/.zplcloud/ के अंतर्गत pgservers.json के रूप में
# { "postgresServers": { "WMS": "Host=pg.internal.lan;Database=wms;Username=zplcloud;Password=..." } }

विकल्प के पीछे का नाम (WMS) वही है जो बाद में चयन सूची में दिखता है। MySQL के लिए विकल्प --mysql है, MariaDB के लिए --mariadb, संबंधित वेरिएबल और फ़ाइलों के साथ।

व्यवहार से एक सुझाव: एक समर्पित डेटाबेस उपयोगकर्ता बनाएँ, जिसके पास ठीक उन्हीं तालिकाओं पर केवल पढ़ने के अधिकार हों जिनकी लेबल को ज़रूरत है। एजेंट हमेशा केवल SELECT चलाता है, लेकिन ऐसा खाता जो इससे अधिक कुछ कर ही न सके, ज़्यादा मज़बूत गारंटी है।

डेटा स्रोत बनाना

डेटा हब → डेटा स्रोत → नया में प्रकार PostgreSQL (एजेंट) या PostgreSQL (Cloud) चुनें, फिर एजेंट और सर्वर। क्वेरी फ़ील्ड में एक अकेला SELECT दर्ज होता है:

SELECT a.sku, a.description, a.ean, s.bin, a.best_before
FROM article a
JOIN stock s ON s.article_id = a.id
WHERE a.active = true

फ़ील्ड बिना कोई डेटा लोड किए कॉलम पढ़ता है - उसके बाद वे डिज़ाइनर में बाइंडिंग के रूप में उपलब्ध होते हैं। टेस्ट करें कनेक्शन की जाँच करता है।

क्वेरी में क्या हो सकता है

नियम जानबूझकर सख्त हैं, क्योंकि डेटा स्रोत पढ़ने के लिए है, लिखने के लिए नहीं:

• केवल एक अकेला SELECT या WITH, कोई सेमीकोलन नहीं, कोई टिप्पणी नहीं, कई स्टेटमेंट नहीं।
• फ़िल्टर मान डेटाबेस तक हमेशा पैरामीटर के रूप में पहुँचते हैं, कभी जोड़े गए टेक्स्ट के रूप में नहीं। इसलिए फ़िल्टर पंक्ति के ज़रिए SQL इंजेक्शन संभव नहीं है।
• फ़िल्टर, सॉर्ट और LIMIT/OFFSET डेटाबेस लागू करता है, प्लेटफ़ॉर्म नहीं। आपके इंडेक्स अपना काम करते हैं।
• प्रति फ़ेच अधिकतम 1000 पंक्तियाँ, 15 सेकंड टाइमआउट।

ये 1000 पंक्तियाँ प्रिंटिंग की सीमा नहीं हैं: बल्क रन के लिए प्लेटफ़ॉर्म सर्वर-साइड एक के बाद एक चंक लाता है, एक बार में 50,000 लेबल तक। मेमोरी में हमेशा केवल एक चंक रहता है।

डेटा कहाँ पहुँचता है

तैयार डेटा स्रोत हर उस जगह उपलब्ध होता है जहाँ डेटा की ज़रूरत हो:

• प्रिंट व्यू - फ़ॉर्म वाला एक सुरक्षित URL, जहाँ कोई EAN से खोजता है और लौटे लेबल को प्रिंट करता है।
• बैच प्रिंटिंग - किसी क्वेरी के सभी परिणाम एक साथ, चंक में प्रिंटर को भेजे जाते हैं।
• डिज़ाइनर - बाइंडिंग डेटा के रूप में, ताकि पूर्वावलोकन प्लेसहोल्डर के बजाय असली मान दिखाए।

आम गलतियाँ

• "The query must start with SELECT." इसे ट्रिगर करने के लिए अंत में एक सेमीकोलन ही काफ़ी है। उसे हटा दें।
• कोई कॉलम नहीं मिला। परिकलित कॉलम को नाम चाहिए: SELECT price 1.19 के बजाय SELECT price 1.19 AS gross।
• कनेक्शन विफल होता है। पहुँच योग्य PostgreSQL सर्वर आमतौर पर TLS पर ज़ोर देते हैं: SSL Mode=Require कनेक्शन स्ट्रिंग में होना चाहिए।
• एजेंट ऑनलाइन नहीं है। एजेंट कनेक्शन स्वयं बनाए रखता है। डेटा हब में एजेंट का अवलोकन दिखाता है कि कौन-से एजेंट मौजूद हैं और वे कौन-से सर्वर रिपोर्ट करते हैं।