Libelektra: yajl: Elektra की बूलियन समर्थित नहीं है

@kodebach यह अभी भी संभव है कि "1" के बजाय "सत्य" को सामान्य करने के लिए टाइप प्लगइन को पुन: कॉन्फ़िगर किया जा सकता है।

नहीं, यह प्रकार प्लगइन द्वारा समर्थित नहीं है, मुझे नहीं पता था कि इसके लिए उपयोग का मामला था।

IMO यह भी समझ में नहीं आता है। एक बूलियन का प्रतिनिधित्व करने का इलेक्ट्रा-तरीका 0 और 1 । यदि कोई संग्रहण प्रारूप प्रकारों का समर्थन करता है, तो Elektra- प्रतिनिधित्व से संग्रहण प्रारूप का प्रतिनिधित्व करने के लिए रूपांतरण, भंडारण प्लगइन द्वारा किया जाना चाहिए। अंत में फॉर्मेट एक्स के लिए स्टोरेज प्लगइन एलेक्ट्रा और फॉर्मेट एक्स के बीच का पुल होना चाहिए।

मूल्यों की बहाली भी बड़ी समस्या नहीं है? पुनर्स्थापना presetstorage , और आपने स्पष्ट रूप से अनुरोध किया है, कि मूल्य निर्धारित करते समय उपयोगकर्ता द्वारा चुने गए प्रतिनिधित्व के लिए हमेशा मान बहाल किए जाते हैं। इसका अर्थ है, यदि आपने अपने उदाहरण में kdb set user/tests/yajl on का उपयोग किया है, तो yajl प्लगइन का मूल्य on प्राप्त होगा।

हमें वास्तव में यहां क्या चाहिए, यह प्रतिनिधित्व को निर्धारित करने का एक तरीका है कि मूल्यों को पुनर्स्थापित किया जाता है, भले ही उपयोगकर्ता कैसे मूल्य निर्धारित करे। यह बहुत आसानी से जोड़ा जा सकता है। हालांकि मुझे यकीन नहीं है कि वर्तमान में एक प्लगइन के लिए एक और प्लगइन से निर्दिष्ट करने का एक तरीका है। मतलब yajl का उपयोग करते समय उपयोगकर्ता को अभी भी type सही तरीके से कॉन्फ़िगर करना होगा।

वे मान हमेशा उपयोगकर्ता द्वारा चुने गए प्रतिनिधित्व के लिए बहाल किए जाते हैं

यह एक समस्या नहीं होगी क्योंकि JSON में केवल उपलब्ध प्रस्तुति सही / गलत है, इसलिए उपयोगकर्ता नहीं चुन सकता है।

मतलब उपयोगकर्ता को अभी भी yajl का उपयोग करते समय सही प्रकार से कॉन्फ़िगर करना होगा।

यह भी कोई समस्या नहीं होगी क्योंकि yajl प्रकार प्लगइन को फिर से कॉन्फ़िगर करने के लिए एक कॉन्फ़िगरेशन / आवश्यकताओं को जोड़ सकता है।

एक बूलियन का प्रतिनिधित्व करने का इलेक्ट्रा-तरीका 0 और 1 है। यदि कोई स्टोरेज प्रारूप प्रकारों का समर्थन करता है, तो एलेक्ट्रा-प्रतिनिधित्व से स्टोरेज फॉर्मेट का प्रतिनिधित्व करने के लिए रूपांतरण, स्टोरेज प्लगइन द्वारा किया जाना चाहिए।

हां, मैं पूरी तरह से सहमत हूं। आपके दृष्टिकोण का लाभ यह है कि यह मध्यवर्ती प्लगइन्स (प्रकार और भंडारण के बीच) को बूलियंस के सही प्रतिनिधित्व को देखने की अनुमति देगा।

मैंने इसे प्रतिबिंबित करने के लिए ऊपर "कार्यान्वयन संकेत" अपडेट किया।

@kodebach एक और सवाल: JSON केवल डबल / बूलियन / स्ट्रिंग का समर्थन करता है। क्या यह संभव है कि टाइप करने वाले प्लगइन से कहा जाए कि केवल इन 3 प्रकारों की अनुमति है?

यह # 1092 में वर्णित JSON प्रकारों को भी ठीक करेगा।

यह एक समस्या नहीं होगी क्योंकि JSON में केवल उपलब्ध प्रस्तुति सही / गलत है, इसलिए उपयोगकर्ता नहीं चुन सकता है।

वे JSON में नहीं चुन सकते हैं, लेकिन वे kdb set का उपयोग करते समय चुन सकते हैं

प्रकार और भंडारण के बीच

आदेश इस तरह से होना चाहिए: getstorage , type , [अन्य], type , setstorage अर्थ, कभी भी किसी भी प्रकार के बीच प्लगइन्स नहीं होना चाहिए और भंडारण।

मैंने इसे प्रतिबिंबित करने के लिए ऊपर "कार्यान्वयन संकेत" अपडेट किया।

अभी भी समस्या है कि kdb set user/tests/yajl on काम नहीं करेगा, type बदलाव के बिना, क्योंकि इस मामले में type मूल्य on सेटस्टोर में पास होंगे लगाना।

JSON केवल डबल / बूलियन / स्ट्रिंग का समर्थन करता है। क्या यह संभव है कि टाइप करने वाले प्लगइन से कहा जाए कि केवल इन 3 प्रकारों की अनुमति है?

कॉन्फ़िगर के माध्यम से अनुमत प्रकारों को प्रतिबंधित करना कठिन नहीं होना चाहिए।

वे JSON में नहीं चुन सकते हैं, लेकिन kdb सेट का उपयोग करते समय वे चुन सकते हैं

kdb set में जो चुना जाता है उसे वैसे भी याद नहीं किया जा सकता है यदि फ़ाइल प्रारूप उसका समर्थन नहीं करता है।

अभी भी समस्या है कि उदाहरण के लिए kdb सेट उपयोगकर्ता / परीक्षण / yajl पर काम नहीं करेगा, प्रकार में परिवर्तन के बिना, क्योंकि इस मामले में प्रकार सेटस्टोरेज प्लगइन पर मूल्य पारित करेगा।

इस मामले में यह "1" में क्यों नहीं बदलता?

कॉन्फ़िगर के माध्यम से अनुमत प्रकारों को प्रतिबंधित करना कठिन नहीं होना चाहिए।

शायद इससे भी फर्क नहीं पड़ता। यदि स्टोरेज प्लगइन या टाइप प्लगइन यह कहता है कि एक प्रकार की अनुमति नहीं है, तो क्या इससे कोई फ़र्क पड़ता है? यह अच्छा होगा यदि भंडारण ट्यूटोरियल भी प्रकारों के बारे में कुछ कहेगा ( @sanssecours ?)

यदि स्टोरेज प्लगइन या टाइप प्लगइन यह कहता है कि एक प्रकार की अनुमति नहीं है, तो क्या इससे कोई फ़र्क पड़ता है?

वह नहीं जिसके बारे में मैं जानता हूं। स्टोरेज प्लगइन में त्रुटि उठाना शायद और भी बेहतर होगा, क्योंकि तब उपयोगकर्ता देखता है कि समस्या yajl type का उपयोग नहीं है।

इस मामले में यह "1" में क्यों नहीं बदलता?

सामान्यकरण / पुनर्स्थापना प्रक्रिया को निम्नलिखित मामलों द्वारा वर्णित किया जा सकता है:

• केस 1: कुंजी kdbGet और kdbGet और kdbSet बीच अपरिवर्तित है
  यह सबसे आसान और सबसे स्पष्ट मामला है। मूल्य kdbGet में सामान्यीकृत किया जाता है और मूल मूल्य kdbSet में पुनर्स्थापित किया जाता है, ताकि अंतर्निहित संग्रहण फ़ाइल अपरिवर्तित रहे (प्रश्न में कुंजी को दबाएं)
• केस 2: कुंजी kdbGet में मौजूद नहीं थी
  यहां हम प्रकार को सत्यापित करने के लिए मान को सामान्य करते हैं और फिर इसे तुरंत बहाल करते हैं।
• केस 3: कुंजी kdbGet मौजूद kdbGet और kdbSet बीच बदल गया था
  यह केस 2 के समान ही आवश्यक है। keySetString origvalue मेटाडेटा निकालता है, इसलिए type प्लगइन के लिए इस तरह की कुंजी kdbGet में मौजूद नहीं थी ।

एक विशेष मामला है। मैंने पहले से ही कार्यक्षमता जोड़ी है जिसका उपयोग यहां किया जा सकता है (मैं इसे इन्फोस / मेटाडेटा में जोड़ना भूल गया):

https://github.com/ElektraInitiative/libelektra/blob/6e609f7e78039db188e32d32d2ea13908c0abe38/src/plinins/type/README.md#L84 -L8888

यदि yajl मेटाडाटा check/boolean/true = true और check/boolean/false = false सभी बूलियन कुंजियों के लिए इंजेक्ट करता है, तो सभी सामान्यीकरण और पुनर्स्थापना के अनुसार काम करना चाहिए। type प्लगइन तब मूल्य true , 1 , false और 0 बूलियन कीज़ के लिए (प्राप्त और सेट में)। लेकिन यह हमेशा true या false सेटस्टोरेज प्लगइन से गुजरेगा। yajl प्लगइन को अभी भी 0 / 1 प्राप्त करना चाहिए और इसे true / false साथ-साथ 0 स्वीकार करना चाहिए 1 सेट में, ताकि यह type प्लगइन के साथ या उसके बिना काम करे।

यदि हम इस तरह से नीचे जाना चाहते हैं, तो हमें इसे बहुत अच्छी तरह से प्रलेखित करना होगा, क्योंकि टाइप प्लग को बढ़ाना अब kdb set में बूलियन कुंजियों के लिए अलग-अलग मानों का उपयोग करने की अनुमति नहीं देगा, क्योंकि yajl गुप्त रूप से उपयोगकर्ता द्वारा दिए गए किसी भी कॉन्फ़िगरेशन को ओवरराइड करता है।

वह नहीं जिसके बारे में मैं जानता हूं। स्टोरेज प्लगइन में त्रुटि उठाना शायद और भी बेहतर होगा, क्योंकि तब उपयोगकर्ता देखता है कि समस्या यह है कि yajl का उपयोग प्रकार का उपयोग नहीं है।

ठीक ठीक।

सामान्यकरण / पुनर्स्थापना प्रक्रिया को निम्नलिखित मामलों द्वारा वर्णित किया जा सकता है
[...] (मैं इसे इन्फोस / मेटाडेटा में जोड़ना भूल गया)

विस्तृत विवरण के लिए धन्यवाद। क्या आप कृपया इसे हमारे दस्तावेज़ में जोड़ सकते हैं?

अब kdb सेट में बूलियन कुंजियों के लिए विभिन्न मानों का उपयोग करने की अनुमति नहीं देगा

"कॉन्फिग / नीड्स" के साथ येजल यह सुनिश्चित कर सकता है कि "चेक / बुलियन / ट्रू = ट्रू और चेक / बुलियन / गलत = गलत" का उपयोग करके टाइप किया गया है।

तो क्या मुझे कार्यान्वयन संकेत बदलना चाहिए?

"कॉन्फिग / नीड्स" के साथ येजल यह सुनिश्चित कर सकता है कि "चेक / बुलियन / ट्रू = ट्रू और चेक / बुलियन / गलत = गलत" का उपयोग करके टाइप किया गया है।

आपने गलत समझा, अभी check/boolean/true और check/boolean/false को एक व्यक्तिगत कुंजी पर मेटाडेटा के रूप में सेट करना है, type के कॉन्फ़िगरेशन में नहीं। कॉन्फ़िगरेशन के भीतर सामान्य समर्थन को जोड़ना होगा (आसान पर्याप्त)।

अछा ठीक है। नहीं, फिर जैसा है उसे छोड़ दें। यह सब कुछ याजल प्लगइन में लागू करने के लिए और अधिक समझ में आता है।
मैंने कार्यान्वयन संकेत के रूप में जोड़ा:

Yajl प्लगइन की जरूरत है:

• [] जेन्सन के झूठे और सच्चे के लिए एलेक्ट्रा के "0" और "1" मूल्यों को प्रस्तुत करें।
• [] प्रकार की त्रुटियों के साथ असफल अगर गैर-समर्थित प्रकार पाए जाते हैं

@sanssecours आप इस जानकारी को स्टोरेज प्लगइन ट्यूटोरियल में जोड़ सकते हैं?

yajl भी मेटाडेटा check/boolean/true = true और check/boolean/false = false प्रत्येक type = boolean साथ प्रत्येक कुंजी में जोड़ना पड़ता है। अन्यथा ऊपर उल्लिखित kdb set /some/key on की समस्या उत्पन्न होगी।

yajl को मेटाडेटा भी जोड़ना होगा

क्या यह भी आवश्यक है कि क्या यूल हमेशा आपको केवल "0" और बूलियन्स के लिए "1" देगा?

हां, क्योंकि समस्या तब होती है, जब उपयोगकर्ता kdbGet बाद मुख्य मूल्य को बदलता है। yajl का उस पर कोई प्रभाव नहीं है।

लेकिन कभी नहीं, हमें type प्लगइन में वैसे भी बदलाव की आवश्यकता है, क्योंकि यदि उपयोगकर्ता एक नई कुंजी जोड़ता है, तो मेटाडेटा मौजूद नहीं होगा और समाधान काम नहीं करेगा।

तो हमें kdbSet पथ में दो बार उपलब्ध होने के लिए टाइप प्लगइन की आवश्यकता है ताकि सामान्यीकरण ठीक से काम करे? क्या आप एक मुद्दा बना सकते हैं?

# 2582 yajl (या उपयोगकर्ता) के साथ बस यह सुनिश्चित करने की आवश्यकता है कि type लिए कॉन्फ़िगरेशन या तो शामिल है

• कोई booleans सरणी और boolean/restore = #1
  या
• एक booleans सरणी है, जिसमें "true" और "false" स्थिति #X और boolean/restore = #X

मैं इसे ठीक करने की कोशिश करूंगा, लेकिन एक सवाल है।

क्या यह एक कुंजी पर type=boolean और type/boolean/restoreas=none सेट करने के लिए पर्याप्त नहीं होना चाहिए कि मैं elektraYajlGet में बूलियन के रूप में पार्स करता हूं? फिर elektraYajlSet मुझे यह कुंजी 1 या 0 के मान से प्राप्त करनी चाहिए, है ना?

लेकिन मैं अभी भी उपयोगकर्ता द्वारा आपूर्ति मूल्य प्राप्त कर रहा हूं

# kdb mount conf.json user/tests/yajl yajl type
# kdb set user/tests/yajl 1
Set string to "1"
# kdb setmeta user/tests/yajl type boolean
# kdb set user/tests/yajl false
Sorry, 1 warning was issued ;(
    Sorry, module yajl issued the warning C03200:
    Validation Semantic: Got boolean which is neither true nor false
Set string to "false"

Case 2: The Key didn't exist in `kdbGet`
  Here we normalize the value to verify the type and then restore it immediately.

@kodebach
क्या यह संभव है कि इस मामले में मूल्य हमेशा बहाल किया जाता है, भले ही type/boolean/restoreas=none ?

/boolean/restoreas अलग-अलग कुंजी के लिए एक पैमाइश नहीं है। यह संपूर्ण माउंटपॉइंट के लिए उपयोग किए जाने वाले type प्लगइन के उदाहरण के लिए कॉन्फ़िगर का हिस्सा है।

मुझे लगता है कि config/needs = type/boolean/restoreas=none के शीर्ष लेख में src/pluigns/yajl/README.md जोड़ना पर्याप्त होना चाहिए। (कम से कम kdb mount बढ़ते हुए)

- infos/config/needs = type/boolean/restoreas=none जोड़ना एक संकलक त्रुटि प्रतीत होती है।

/elektra/build/src/plugins/yajl/readme_yajl.c:11:55: error: expected ‘)’ before ‘keyNew’
 "- infos/config/needs = type/boolean/restoreas=none\n"
                                                       ^
                                                       )

क्या मैं प्रोग्राम को कुंजी भी सेट कर सकता हूं? मैं किसी अन्य प्लगइन को कॉन्फ़िगर करने के तरीके के बारे में दस्तावेज़ीकरण नहीं पा सकता हूं।

मुझे लगता है कि यह सिर्फ config/need नहीं infos/config/needs । मैं हालांकि अभी इसे सत्यापित नहीं कर सकता।

README का हेडर keyNew की लाइनों में बदल जाता है, जिसे आप तब प्लगइन्स get विधि में शामिल करते हैं। आप मैन्युअल रूप से सामान जोड़ सकते हैं, README का उपयोग करना पसंद किया जाता है, क्योंकि यह स्वचालित रूप से प्रलेखन प्रदान करता है।

क्या मैं प्रोग्राम को कुंजी भी सेट कर सकता हूं?

हां, बस इसे अनुबंध कुंजी सेट में जोड़ें। उदाहरण के लिए, निम्न पंक्ति दिखाती है कि कैसे YAML CPP type प्लगइन को कॉन्फ़िगर करता है:

https://github.com/ElektraInitiative/libelektra/blob/5519cb8066a096215a3701ca3d8c02fcebe54914/src/plugins/yamlcpp/yamlcpp.cpp#L4444
।

आप दोनों को धन्यवाद!

# 3012 के साथ, yajl plugin में निम्न व्यवहार है।

प्रकार प्लगइन के साथ

kdb mount conf.json user/tests/yajl yajl type
kdb set user/tests/yajl 1
kdb get user/tests/yajl
#> 1
kdb setmeta user/tests/yajl type boolean
kdb set user/tests/yajl on
kdb get user/tests/yajl
#> 1
kdb set user/tests/yajl/subkey disable
kdb setmeta user/tests/yajl/subkey type boolean
kdb get user/tests/yajl/subkey
#> 0

cat `kdb file user/tests/yajl`
{
    "___dirdata": true,
    "subkey": true
}

प्रकार प्लगइन के बिना

yajl प्लगइन को अभी भी 0 / 1 प्राप्त करना चाहिए और इसे true / false और 0 स्वीकार करना चाहिए 1 सेट में, ताकि यह type प्लगइन के साथ या उसके बिना काम करे।

kdb mount conf.json user/tests/yajl yajl
kdb set user/tests/yajl 1
kdb getmeta user/tests/yajl type
#> boolean
kdb set user/tests/yajl false
kdb getmeta user/tests/yajl type
#> boolean
kdb get user/tests/yajl
#> 0

# Without the type plugin, 'on' is mapped to a string and a warning is emitted.
kdb set user/tests/yajl on
#> RET: 2

* fail with type errors if non-supported types are found

क्या यह संदर्भित करता है कि टाइप प्लगइन कब माउंट किया जाता है या इसके बिना?

इस अंतिम मामले में, अब तक का व्यवहार यह था कि एक चेतावनी उत्सर्जित की जाती है।

 Sorry, 1 warning was issued ;(
    Sorry, module yajl issued the warning C03200:
    Validation Semantic: Got boolean which is neither 1 or true nor 0 or false

मुझे लगता है कि यह अभी भी ठीक है, टाइप प्लगइन के बिना, टाइपिंग जाँच नहीं होनी चाहिए।

वास्तव में, इसे "1" या "0" के अलावा किसी भी चीज़ के बारे में चेतावनी (या विफल) होनी चाहिए। इसके अलावा "सच", "झूठे" इलेक्ट्रा के बूलियन नहीं हैं।

Imho, yajl प्लगइन में टाइप प्लगइन के लिए "आवश्यकता" निर्भरता होनी चाहिए। (लेकिन पहले हमें "संख्या" को भी ठीक करने की आवश्यकता है, क्योंकि यह इलेक्ट्रा के प्रकारों में से एक नहीं है)।

वास्तव में, इसे "1" या "0" के अलावा किसी भी चीज़ के बारे में चेतावनी (या विफल) होनी चाहिए। इसके अलावा "सच", "झूठे" इलेक्ट्रा के बूलियन नहीं हैं।

@kodebach ने लिखा

Yajl plugin को अभी भी 0/1 रिटर्न प्राप्त करना चाहिए और इसे सही / गलत और साथ ही सेट में 0/1 को स्वीकार करना चाहिए, ताकि यह टाइप प्लगइन के साथ या इसके बिना काम करे।

यही कारण है कि मैं भी "सच" और "झूठे" की अनुमति देता हूं।

Imho, yajl प्लगइन में टाइप प्लगइन के लिए "आवश्यकता" निर्भरता होनी चाहिए। (लेकिन पहले हमें "संख्या" को भी ठीक करने की आवश्यकता है, क्योंकि यह इलेक्ट्रा के प्रकारों में से एक नहीं है)।

हां, मैं पूरी तरह से निर्भरता के बारे में सहमत हूं। फिर हम "सच्चे" और "झूठे" के लिए समर्थन निकाल सकते हैं।

संख्या की समस्या के बारे में: याजल संख्या प्रकार को दोगुना करने के लिए मैप करता है, जो ठीक है, मुझे लगता है। और जल्दी से जाँच करने से, प्रकार प्लगइन का डबल प्रकार भी json के ई-संकेतन का समर्थन करता है (अर्थात 3.4e2 )।
आप समस्या के रूप में क्या देखते हैं?

आप समस्या के रूप में क्या देखते हैं?

आह, अब मैं देख रहा हूँ कि src / plugins / yajl / testmod_yajl.c 240-251 पर टिप्पणी की गई है। इसे हटाया जाना चाहिए। (अभी भी संख्या की घटना है।)