libelektra: yajl: Elektra's boolean not supported

Can I programmatically set the key too?

Yep, just add it to the contract key set. For example, the following line shows how YAML CPP configures the type plugin:

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

I think it should just be config/need not infos/config/needs. I can’t verify it right now though.

The header of the README is turned into lines of keyNew, which you then include into the plugins get method. You could manually add stuff there, using the README is preferred, since it automatically provides documentation.

No this is not supported by the type plugin, I didn’t know there was a use case for this.

IMO it also doesn’t make sense. The Elektra-way of representing a boolean is 0 and 1. If a storage format supports types, the conversion from the Elektra-representation to the representation of the storage format, should be done by the storage plugin. In the end the storage plugin for format X should be the bridge between Elektra and format X.

Thank you both!

With #3012, the yajl plugin has the following behavior.

With the type 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
}

Without the type plugin

The yajl plugin should still return 0/1 in get and it should accept true/false as well as 0/1 in set, so that it works with or without the type plugin.

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

Does that refer to when the type plugin is mounted or without?

In this last case, the behavior until now was that a warning is emitted.

 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

I think this is still fine, since without the type plugin, there shouldn’t be type checking.

No. With #2582 yajl (or the user) just needs to make sure that the config for type either contains

• no booleans array and boolean/restore = #1 or
• has a booleans array which contains "true" and "false" at position #X and boolean/restore = #X

Yes, because the problem occurs, when the user changes the key value after kdbGet. yajl has no influence on that.

But nevermind that, we need changes to the type plugin anyway, because if the user adds a new key, the metadata will not be present and the solution won’t work.

yajl also has to add the metadata check/boolean/true = true and check/boolean/false = false to each key with type = boolean. Otherwise the problem for kdb set /some/key on mentioned above will occur.