Cardano-db-sync: टेस्टनेट पर यूनिकोड के कारण अपवाद

यह गर्दन में बहुत बड़ा दर्द है।

जो tx मेटाडेटा डाला जा रहा है वह है

(1,S "\NUL\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX\ETX")

जिसे JSON के रूप में एन्कोड किया जा रहा है:

"\u0000\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003"

कौन सा निश्चित रूप से मान्य UTF8 नहीं है और इसलिए डेटाबेस इसे अस्वीकार कर देता है।

इससे भी बदतर, ऊपर दिखाए गए अनुसार हास्केल Text लाइब्रेरी द्वारा यूटीएफ 8 के रूप में एन्कोड किया गया है, लेकिन पोस्टग्रेएसक्यूएल इसे अस्वीकार कर देता है।

मैं दोहराता हूं कि यह गर्दन में कितना बड़ा दर्द है।

प्रश्न में स्ट्रिंग को हास्केल Text लाइब्रेरी द्वारा यूटीएफ 8 में डीकोड किया गया है और फिर पोस्टग्रेस को पास कर दिया गया है जो SqlError अपवाद फेंकता है। मैंने इस अपवाद को पकड़ने की कोशिश की है लेकिन अपवाद को पकड़ना काम नहीं कर रहा है।

मैं अपवाद को पकड़ और लॉग कर सकता हूं:

[db-sync-node:Warning:37] [2020-09-21 00:26:18.77 UTC] insertTxMetadata: Failed to insert (1,S "\NUL...\ETX")
SqlError {sqlState = "22P05", sqlExecStatus = FatalError, sqlErrorMsg
 = "unsupported Unicode escape sequence", sqlErrorDetail = "\\u0000 cannot be converted to text.", sqlErrorHint = ""}

लेकिन फिर दूसरा अपवाद है:

[db-sync-node:Error:37] [2020-09-21 00:26:18.77 UTC] runDBThread: SqlError {sqlState = "25P02", sqlExecStatus = FatalError, sqlErrorMsg = "current transaction is aborted, commands ignored until end of transaction
 block", sqlErrorDetail = "", sqlErrorHint = ""}

इससे पता चलता है कि सम्मिलन से पहले मुझे JSON को पूरी तरह से सत्यापित करने की आवश्यकता है।

हम PostgreSQL में अमान्य UTF8 को स्टोर कर सकते हैं, लेकिन केवल bytea डेटा के रूप में jsonb रूप में नहीं और यदि हम पूर्व Postgres के JSON क्वेरी समर्थन के लिए जाते हैं तो यह उपलब्ध नहीं होगा।

मैंने मैन्युअल यूटीएफ 8 डीकोड की कोशिश की है:

decodeUtf8IO :: ByteString -> IO (Either Text.UnicodeException Text)
decodeUtf8IO = try . evaluate . Text.decodeUtf8With Text.strictDecode

और उसकी भी यही समस्या है।

से: https://stackoverflow.com/questions/31671634/handling-unicode-sequences-in-postgresql

PostgreSQL स्ट्रिंग में एक नल बाइट कानूनी नहीं है। न तो शून्य कोड बिंदु है।

वर्तमान में सोचें कि यह हास्केल/पर्सिस्टेंट ने पोस्टग्रेज को भेजने के लिए इसे क्रमबद्ध करने के तरीके के कारण है। वर्तमान में इस सिद्धांत को प्रमाणित करने का प्रयास कर रहे हैं।

Aeson.encode पहले से ही NUL char से \u0000 बच जाता है जिसे Persistent तब अस्वीकार कर देता है।

इसके लिए साफ-सुथरी व्यवस्था करना आसान नहीं होगा।

मैं इसे देख रहा था और ऐसा लगता है कि ये गुण हैं:

• "\u0000\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003\u0003" UTF-8 के रूप में काफी मान्य है, क्योंकि UTF-8 \u0000 को सीधे प्रदर्शित करने की अनुमति देता है।
• \u0000 लिए jsonb की अनुमति नहीं है क्योंकि इसे text परिवर्तित नहीं किया जा सकता है।

इसे JSON में एन्कोड करने का एकमात्र अस्थायी समाधान, और फिर Text और फिर खराब वर्ण अनुक्रम का पता लगाएं और खराब अनुक्रम होने पर JSON ऑब्जेक्ट को अस्वीकार कर दें। मुझे यह भी आश्चर्य होता है कि क्या \u0000 एकमात्र अनुक्रम है जिसे मुझे अस्वीकार करने की आवश्यकता है,

क्या आप दो कॉलम स्टोर नहीं कर सके? बाइटा, और JSON जब इसमें गैर-पाठ वर्ण नहीं होता है, ताकि कोई भी अपनी आवश्यकता के अनुसार उपयोग करने के लिए स्वतंत्र हो।

@erikd \u0000 प्रतिबंध स्पष्ट रूप से यहां बताया गया

एक टपका हुआ अमूर्तन से बचने के लिए, सटीक मान (जैसा कि उपयोगकर्ता द्वारा दिया गया है) संग्रहीत किया जाना चाहिए। इसका मोटे तौर पर मतलब है या तो एक ब्लॉब (= डीबी में कोई संरचना नहीं) या जेएसओएन स्ट्रिंग मान जो किसी भी तरह मूल अर्थ को संरक्षित करते हैं: उदाहरण के लिए डीबी में बेस 64-एन्कोडेड स्ट्रिंग मान (इसलिए एप्लिकेशन में अतिरिक्त प्रसंस्करण की कीमत पर संरचना को पुनर्प्राप्त करना बेस 64 से वास्तविक मूल्य में अनुवाद करने का आदेश)।

अस्थायी वर्कअराउंड फ़िक्स (केवल मेटाडेटा ऑब्जेक्ट्स को छोड़ना जो पोस्टग्रेज़ में सम्मिलित नहीं किया जा सकता) को मास्टर में विलय कर दिया गया है।

यह अब अस्थायी फिक्स के साथ कैसा दिखता है:

[db-sync-node:Info:37] [2020-09-22 10:19:09.66 UTC] insertShelleyBlock: epoch 84, slot 6060000, block 1816721, hash 3ec15354c53deae4eb26a206cc3185f799e80bd09393f279bce7e53a7d633144
[db-sync-node:Warning:37] [2020-09-22 10:19:24.08 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Warning:37] [2020-09-22 10:19:24.08 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Warning:37] [2020-09-22 10:19:24.10 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Warning:37] [2020-09-22 10:19:24.10 UTC] insertTxMetadata: dropped due to a Unicode NUL character.
[db-sync-node:Info:37] [2020-09-22 10:19:24.93 UTC] insertShelleyBlock: epoch 84, slot 6065000, block 1816973, hash 0ab0dd5c36c6eb480b8bbd05508be952c5ed8597a4e422af25bd80a905a9368d

क्या डॉकटर की मरम्मत की गई है, और मरम्मत का संस्करण क्या है

यह तय नहीं है, लेकिन 5.0.x (लेकिन मैं अनुशंसा करता हूं 5.0.2 ) में एक वर्कअराउंड है जो यूनिकोड NUL वर्ण वाले tx_metadata को छोड़कर इस समस्या से बचाता है।