using spec.ini and spectest.ini from examples/spec gives me:

[test/#2]
 logs/spec/info = #0
 logs/spec/info/#0 = system/testkey/test/#2 has missing subkeys: a
 arrayMeta = array
 conflict/missing/#0 = a

  [testkey/test/#/a]
  require =

if you add conflict/{s,g}et/require ERROR to the specs configuration it should fail with an error

Error (#142) occurred!
Description: globbing error
Ingroup: plugin
Module: spec
At: /home/thomas/Dev/Elektra/libelektra/src/plugins/spec/spec.c:483
Reason: user/testkey/test/#0 has missing subkeys: a

just tested it with ERROR, works for me, but the configuration of spec really is confusing because there are so many options to set

Can you please bring a full example how you tested it with ERROR?

And what about the disappear of required? Meta data required was set in spec/-namespace, and after spec plugin it isn't anymore. Is this a separate issue?

And what is the difference of require and required? Is this a typo in examples/spec/spec.ini?

require means that a key is required, required defines the number of subkeys that are required.
guess we should rename required

by setting system/elektra/globalplugins/postcommit/user/plugins/#0/conflict/get to ERROR spec would yield an error if a key with require metadata is missing

require means that a key is required, required defines the number of subkeys that are required.

This was not explained in METADATA.ini, please update.

I would suggest to rename required to require/range or require/number. See also my proposal with array/range in METADATA.ini.

error if a key with require metadata is missing

Does not work for me, I have both (conflict/{get,set} to ERROR (there are range and conflict, subkeys though)), and simplespeclang yields require (see 7936bec) but the validation still does not fail.

or per-key config:

 % kdb export system/elektra/globalplugins/postcommit/user/plugins/#0
= spec
placements = spec
placements/error =
placements/get = postgetstorage
placements/set = presetstorage


 % cat /tmp/spec.ini
#@META require = 1
#@META conflict/get/missing = ERROR
[test/a]

 % kdb mount /tmp/spec.ini spec ini
 % kdb set /test test
Using name user/test
Create a new key user/test with string test

 % kdb get /test
test
Error (#142) occurred!
Description: globbing error
Ingroup: plugin
Module: spec
At: /home/thomas/Dev/libelektra/src/plugins/spec/spec.c:483
Reason: user/test has missing subkeys: a

Mountpoint: /test
Configfile: /tmp/spec.ini

For me require and required are removed:

> kdb lsmeta spec/tutorial/schema/notation
check/enum
check/enum/#0
check/enum/#1
check/enum/#2
check/enum/#3
mandatory
require
required
> kdb lsmeta /tutorial/schema/notation
check/enum
check/enum/#0
check/enum/#1
check/enum/#2
check/enum/#3
mandatory

I wonder how it can fail at all, I thought global plugins do not have a way to fail kdb?
I now tried to also set per-key config 0f85a35
If you run the commands of doc/tutorials/validation.md (section "Customized schemas") and then do:

> kdb import -s validate -c "format=% : %" /tutorial/schema simpleini << HERE
notation : graph
applied-to : small
HERE

So import works even though keys are missing:

> kdb ls user/tutorial/schema
user/tutorial/schema/applied-to
user/tutorial/schema/notation

spec removes all plugin-specific metakeys postgetstorage

spec removes all plugin-specific metakeys postgetstorage

which is, in this case, not a good idea, require is already set by the spec namespace, so it is not really plugin-specific.

[examples for set]

Yes, I know it works well for small examples. But with multiple keys (where some of that are set) and multiple plugins involved (e.g. enum) there are plenty of issues. It is hard to reproduce something minimalistic but I think if you do whats shown in the tutorial you will find the issues easily.

ok, found the issue.
if spec/example/_/key has require spec looks for every key matching /example/* and tests for every found key if it has a subkey named key. if no key matching /example/* is found nothing happens

for spec/example/key with require spec looks for the key /example

my intent was for keys like spec/example/#/key to match all the existing members of the array /example/#* and require them to have a subkey key

Is it easy to be fixed?

not really, it's more like an different approach and works fine for what it does (e.g require every array member to have a specific subkey)
but i'll add a non-wildcard version for the next release too

Can we make "postcommit/user/plugins/#0/conflict/get = ERROR" the default please?

I would like that require works for lcdproc out of the box.

And require seems to be not documented in doc/METADATA.ini.

In #2705 (comment) Markus wrote:

we already have #1024 for this. It would be great if you can clean this mess up. I am not sure if we need it for LCDproc, though. I think it would be better to have defaults everywhere.

While it is true that having defaults everywhere is preferrable, LCDproc is actually the perfect example for when require is needed.

A simple example are the displaynames of menus and commands (also the envnames of parameters) in the lcdexec client. In the old version these defaulted to the name of the INI section, which obviously had to be set. Since this is no longer possible, and there simply is no good default for the displayname, it should be required.

Another (even clearer) example, is the ring parameter type. It lets the user select from a set of predefined strings. These strings are given as an array in the config. These strings are per definition required, since we want to provide a selection to the user.

Ok, if require is required, then it is required. Important is that the application will not start up (elektraOpen) not succeed if required keys are missing. Otherwise we lose the guarantees of elektraGet.

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue.
Thank you for your contributions 💖