Libelektra: yajl: логическое значение Elektra не поддерживается

@kodebach все еще возможно, что плагин типа может быть переконфигурирован для нормализации до "true" вместо "1".

Нет, это не поддерживается плагином типа, я не знал, что для этого есть вариант использования.

ИМО это тоже не имеет смысла. Электра-способ представления логического значения - 0 и 1 . Если формат хранения поддерживает типы, преобразование из представления Elektra в представление формата хранения должно выполняться плагином хранения. В конце концов, плагин хранения для формата X должен стать мостом между Elektra и форматом X.

И разве не большая проблема - восстановление ценностей? Восстановление выполняется в presetstorage , и вы явно запросили, чтобы значения всегда восстанавливались до представления, выбранного пользователем при установке значения. Это означает, что если вы использовали kdb set user/tests/yajl on в своем примере, плагин yajl получит значение on .

Что нам здесь действительно нужно, так это способ установить представление, в которое восстанавливаются значения, независимо от того, как пользователь установил значение. Это можно очень легко добавить. Однако я не уверен, что в настоящее время есть способ указать конфигурацию для плагина из другого плагина. Это означает, что пользователю все равно придется правильно настроить type при использовании yajl .

что значения всегда восстанавливаются до представления, выбранного пользователем

Это не будет проблемой, поскольку в JSON единственное доступное представление - истина / ложь, поэтому пользователь не может выбирать.

Это означает, что пользователю все равно придется правильно настроить тип при использовании yajl.

Это также не будет проблемой, потому что yajl может добавить конфигурацию / необходимо перенастроить плагин типа.

Elektra-способ представления логического значения - это 0 и 1. Если формат хранения поддерживает типы, преобразование из Elektra-представления в представление формата хранения должно выполняться плагином хранения.

Да, полностью согласен. Преимущество вашего подхода в том, что он также позволит промежуточным плагинам (между типом и хранилищем) видеть правильное представление логических значений.

Я обновил «Совет по реализации» выше, чтобы отразить это.

@kodebach другой вопрос: JSON поддерживает только double / boolean / string. Можно ли сказать плагину типов, что разрешены только эти 3 типа?

Это также исправит типы JSON, упомянутые в # 1092.

Это не будет проблемой, поскольку в JSON единственное доступное представление - истина / ложь, поэтому пользователь не может выбирать.

Они не могут выбирать в JSON, но могут выбирать при использовании kdb set

между типом и хранением

Порядок должен быть таким: getstorage , type , [other], type , setstorage означает, что между типами не должно быть никаких плагинов. и хранение.

Я обновил «Совет по реализации» выше, чтобы отразить это.

По-прежнему существует проблема, что, например, kdb set user/tests/yajl on не будет работать без изменений type , потому что в этом случае type передаст значение on в setstorage. плагин.

JSON поддерживает только двойные / логические / строковые. Можно ли сказать плагину типов, что разрешены только эти 3 типа?

Ограничить разрешенные типы с помощью config не должно быть сложно.

Они не могут выбирать в JSON, но могут выбирать при использовании набора kdb

То, что выбрано в kdb set все равно нельзя запомнить, если формат файла не поддерживает это.

По-прежнему существует проблема, что, например, kdb set user / tests / yajl on не будет работать без изменения типа, потому что в этом случае type передаст значение в плагин 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 для логических ключей (в get и set), но он всегда будет передавать true или false в плагин setstorage. Плагин yajl прежнему должен возвращать 0 / 1 в get и должен принимать 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 должен:

• [] преобразовать значения «0» и «1» Elektra в ложные и истинные значения 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 array и 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#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 в get и должен принимать 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». Также «true», «false» не являются логическими значениями Elektra.

Imho, плагин yajl должен иметь зависимость типа «require» от типа. (но сначала нам нужно исправить «число», так как это не один из типов Elektra).

Фактически, он должен предупреждать (или даже выходить из строя) обо всем, кроме «1» или «0». Также «true», «false» не являются логическими значениями Elektra.

@kodebach написал

Плагин yajl должен по-прежнему возвращать 0/1 в get и принимать true / false, а также 0/1 в set, чтобы он работал с плагином типа или без него.

Это то, что я также разрешаю "истина" и "ложь".

Imho, плагин yajl должен иметь зависимость типа «require» от типа. (но сначала нам нужно исправить «число», так как это не один из типов Elektra).

Да, я полностью согласен с зависимостью. Затем мы можем убрать поддержку «истины» и «ложи».

Что касается числовой проблемы: Yajl сопоставляет тип Number как double, и я думаю, это нормально. И, судя по быстрой проверке, тип double плагина типа также поддерживает E-нотацию json (т.е. 3.4e2 ).
В чем вы видите проблему?

В чем вы видите проблему?

Ах, теперь я вижу, что src / plugins / yajl / testmod_yajl.c 240-251 закомментирован. Это следует удалить. (Число еще встречается.)