Libelektra: yajl: منطقية Elektra غير مدعومة

kodebach هل لا يزال من الممكن إعادة تكوين المكون الإضافي للنوع للتطبيع إلى "true" بدلاً من "1".

لا ، هذا غير مدعوم من قبل نوع المكون الإضافي ، لم أكن أعرف أن هناك حالة استخدام لهذا.

IMO كما أنه لا معنى له. طريقة Elektra لتمثيل منطقية هي 0 و 1 . إذا كان تنسيق التخزين يدعم الأنواع ، فيجب أن يتم التحويل من تمثيل Elektra إلى تمثيل تنسيق التخزين بواسطة مكون التخزين الإضافي. في النهاية ، يجب أن يكون المكون الإضافي للتخزين للتنسيق X هو الجسر بين Elektra و format X.

أيضا أليست المشكلة الأكبر هي استعادة القيم؟ تتم الاستعادة في presetstorage ، وقد طلبت صراحةً ، استعادة القيم دائمًا إلى التمثيل الذي يختاره المستخدم ، عند تعيين القيمة. هذا يعني أنك إذا استخدمت kdb set user/tests/yajl on في مثالك ، فإن المكوّن الإضافي yajl سيتلقى القيمة on .

ما نحتاجه هنا في الواقع ، هو طريقة لتعيين التمثيل الذي يتم استعادة القيم إليه ، بغض النظر عن كيفية تعيين المستخدم للقيمة. يمكن إضافة هذا بسهولة بالغة. ومع ذلك ، لست متأكدًا من وجود طريقة حاليًا لتحديد تكوين مكون إضافي ، من مكون إضافي آخر. بمعنى أنه لا يزال يتعين على المستخدم تكوين type بشكل صحيح عند استخدام yajl .

يتم دائمًا استعادة القيم إلى التمثيل الذي يختاره المستخدم

لن تكون هذه مشكلة لأن العرض الوحيد المتاح في JSON هو صواب / خطأ ، لذلك لا يمكن للمستخدم الاختيار.

مما يعني أنه لا يزال يتعين على المستخدم تكوين الكتابة بشكل صحيح عند استخدام yajl.

لن يكون هذا أيضًا مشكلة لأن yajl يمكنه إضافة config / needs لإعادة تكوين المكون الإضافي للنوع.

طريقة Elektra لتمثيل منطقي هي 0 و 1. إذا كان تنسيق التخزين يدعم الأنواع ، فيجب أن يتم التحويل من تمثيل Elektra إلى تمثيل تنسيق التخزين بواسطة مكون التخزين الإضافي.

نعم ، أوافق تمامًا. تتمثل ميزة منهجك في أنه سيسمح أيضًا للمكونات الإضافية الوسيطة (بين النوع والتخزين) برؤية التمثيل الصحيح للمنطق المنطقي.

لقد قمت بتحديث "تلميح التنفيذ" أعلاه ليعكس ذلك.

kodebach سؤال آخر: JSON يدعم فقط double / boolean / string. هل من الممكن أن نقول للنوع المساعد أن هذه الأنواع الثلاثة فقط مسموح بها؟

سيؤدي هذا أيضًا إلى إصلاح أنواع JSON المذكورة في # 1092.

لن تكون هذه مشكلة لأن العرض الوحيد المتاح في JSON هو صواب / خطأ ، لذلك لا يمكن للمستخدم الاختيار.

لا يمكنهم الاختيار في JSON ، لكن يمكنهم الاختيار عند استخدام kdb set

بين النوع والتخزين

يجب أن يكون الطلب على النحو التالي: getstorage ، type ، [other] ، type ، setstorage ، بمعنى أنه لا يجب أن يكون هناك أي مكونات إضافية بين النوع والتخزين.

لقد قمت بتحديث "تلميح التنفيذ" أعلاه ليعكس ذلك.

لا تزال هناك مشكلة ، على سبيل المثال ، لن يعمل kdb set user/tests/yajl on ، بدون تغييرات على type ، لأنه في هذه الحالة type سيمرر القيمة on إلى setstorage توصيل في.

يدعم JSON فقط double / boolean / string. هل من الممكن أن نقول للنوع المساعد أن هذه الأنواع الثلاثة فقط مسموح بها؟

لا ينبغي أن يكون من الصعب تقييد الأنواع المسموح بها عبر ملف config.

لا يمكنهم الاختيار في JSON ، لكن يمكنهم الاختيار عند استخدام مجموعة kdb

ما تم اختياره في kdb set لا يمكن تذكره على أي حال إذا كان تنسيق الملف لا يدعمه.

لا تزال هناك مشكلة تتمثل في أن kdb set user / tests / yajl on لن يعمل ، بدون تغييرات على الكتابة ، لأنه في هذه الحالة سيمرر النوع القيمة إلى البرنامج المساعد setstorage.

لماذا لا يتحول إلى "1" في هذه الحالة؟

لا ينبغي أن يكون من الصعب تقييد الأنواع المسموح بها عبر ملف config.

ربما لا يهم حتى. هل يُحدث فرقًا إذا قال البرنامج المساعد التخزين أو المكون الإضافي للنوع أن النوع غير مسموح به؟ سيكون من الجيد أن يقول برنامج التخزين التعليمي أيضًا شيئًا عن الأنواع ( 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/plugins/type/README.md#L84 -L88

إذا قام yajl بحقن البيانات الوصفية check/boolean/true = true و check/boolean/false = false لجميع المفاتيح المنطقية ، يجب أن تعمل جميع عمليات التسوية والاستعادة على النحو المنشود. سيقبل المكون الإضافي type القيم true ، 1 ، false و 0 للمفاتيح المنطقية (in get and set) ، ولكنه سيمرر دائمًا true أو false إلى المكوّن الإضافي setstorage. يجب أن يستمر المكون الإضافي yajl بإرجاع 0 / 1 في الحصول عليه ويجب أن يقبل true / false بالإضافة إلى 0 / 1 في المجموعة ، بحيث يعمل مع أو بدون المكوّن الإضافي type .

إذا اخترنا النزول بهذه الطريقة ، فعلينا توثيقه جيدًا ، لأن تثبيت البرنامج المساعد من النوع لن يسمح بعد الآن باستخدام قيم مختلفة للمفاتيح المنطقية في kdb set ، لأن yajl سرًا يتجاوز أي تكوين قدمه المستخدم.

ليس هذا ما أعلمه عن. ربما يكون من الأفضل رفع الخطأ في ملحق التخزين ، لأن المستخدم حينها يرى أن المشكلة تكمن في استخدام yajl وليس استخدام النوع.

بالضبط.

يمكن وصف إجراء التطبيع / الاستعادة في الحالات التالية
[...] (لقد نسيت إضافته إلى المعلومات / البيانات الوصفية)

شكرا لشرح مفصل. هل يمكنك إضافة هذا إلى وثائقنا من فضلك؟

لن يسمح بعد الآن باستخدام قيم مختلفة للمفاتيح المنطقية في مجموعة kdb

باستخدام "config / needs" ، يمكن لـ yajl التأكد من أن النوع مثبت باستخدام "check / boolean / true = true و check / boolean / false = false".

فهل يجب علي تغيير تلميح التنفيذ؟

باستخدام "config / needs" ، يمكن لـ yajl التأكد من أن النوع مثبت باستخدام "check / boolean / true = true و check / boolean / false = false".

لقد أسأت الفهم ، الآن يجب تعيين check/boolean/true و check/boolean/false كبيانات وصفية على مفتاح فردي ، وليس في التكوين type . يجب إضافة الدعم العام داخل التكوين (سهل بما فيه الكفاية).

موافق. لا ، ثم اتركه كما هو. من المنطقي تنفيذ كل شيء في البرنامج المساعد yajl.
أضفت كتلميح تنفيذ:

يحتاج البرنامج المساعد yajl إلى:

• [] عرض قيم Elektra "0" و "1" على خطأ وصحيح في JSON.
• [] تفشل مع أخطاء النوع إذا تم العثور على أنواع غير مدعومة

sanssecours هل يمكنك إضافة هذه المعلومات إلى البرنامج التعليمي

yajl أيضًا إضافة البيانات الوصفية check/boolean/true = true و check/boolean/false = false لكل مفتاح مع type = boolean . وإلا ستحدث مشكلة kdb set /some/key on المذكورة أعلاه.

يجب على yajl أيضًا إضافة البيانات الوصفية

هل هذا ضروري أيضًا إذا كان 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.

تضمين التغريدة
هل من الممكن في هذه الحالة استعادة القيمة دائمًا حتى لو كان 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#L44
.

شكرا لكما!

مع # 3012 ، يمتلك البرنامج المساعد yajl السلوك التالي.

مع نوع البرنامج المساعد

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 تبعية "تتطلب" لنوع البرنامج المساعد. (ولكن نحتاج أولاً أيضًا إلى إصلاح "الرقم" ، لأنه ليس أحد أنواع Elektra).

في الواقع ، يجب أن تحذر (أو حتى تفشل) بشأن أي شيء باستثناء "1" أو "0". كما أن "صواب" و "خطأ" لا يمثلان قيم منطقية لإلكترا.

كتب kodebach

لا يزال من المفترض أن يعرض المكون الإضافي yajl 0/1 في get ويجب أن يقبل true / false بالإضافة إلى 0/1 في المجموعة ، بحيث يعمل مع أو بدون نوع البرنامج المساعد.

هذا ما أسمح به أيضًا "صواب" و "خطأ".

Imho ، يجب أن يكون للمكوِّن الإضافي yajl تبعية "تتطلب" لنوع البرنامج المساعد. (ولكن نحتاج أولاً أيضًا إلى إصلاح "الرقم" ، لأنه ليس أحد أنواع Elektra).

نعم ، أنا أوافق تمامًا على التبعية. ثم يمكننا إزالة الدعم لكل من "صواب" و "خطأ".

فيما يتعلق بمشكلة الرقم: يجل يعيّن نوع الرقم لمضاعفة ، وهو أمر جيد على ما أعتقد. ومن التحقق السريع ، فإن النوع المزدوج من النوع الإضافي يدعم أيضًا تدوين json's E-notation (على سبيل المثال 3.4e2 ).
ماذا ترى كمشكلة؟

ماذا ترى كمشكلة؟

آه ، أرى الآن أنه تم التعليق على src / plugins / yajl / testmod_yajl.c 240-251. يجب إزالة هذا. (لا يزال هناك تكرار للعدد.)