Libelektra: spec: globbing problems

[kodebach]

The spec plugin doesn't do globbing correctly:

• The # glob should query the array size and should copy metadata to non-existent keys within the array bounds as well. Otherwise something like kdb get array/#0 won't work, even if the specification contains a default value for array/#. Setting the fallback metadata might also be a solution.
• The same problem exists for _, however, I don't really see a solution there, because you can't create all possible keys.

Where possible, the spec plugin should also use the globbing library.

[markus2330]

The same problem exists for _, however, I don't really see a solution there, because you can't create all possible keys.

I am not sure if we really need this?

We could provide the (real) parentKey to the plugins. Then spec would know which key to create. This would of course not help for every applications but only for something like kdb get.

@tom-wa always wanted the (real) parentKey for the multiresolver, so that not all files need to be loaded in kdbGet.

Where possible, the spec plugin should also use the globbing library.

I fully agree.

[kodebach]

We could provide the (real) parentKey to the plugins.

What do yo mean by that? And how would that solve the problem? Take for example this specification. Specifically the key menu/menu/_/displayname.

The intention was that for every menu there would be a named entry under menu/menu/. But if you try to lookup menu/menu/test/displayname, the spec plugin would magically have to know in advance to create this key. Obviously this can't work (and that should be mentioned in the docu), but it should work, if menu/menu/test exists. That however is also not the case right now.

What would also work is using # instead of _ (once the bug is fixed).

Basically, right now the globbing in spec is only useful for kdbSet() calls.

[markus2330]

What do yo mean by that? And how would that solve the problem?

It would only help in the case of kdb get /some/specific/key as then the spec plugin would have /some/specific/key as parent Key and could create it (even if the spec contains globs).

Basically, right now the globbing in spec is only useful for kdbSet() calls.

Yes, the spec plugin was also created for validation (which happens in kdbSet).

[markus2330]

This bug seems to be more urgent then I knew (it seems to also affect all drivers, I thought it is only about the menu system).

What we could do is (brainstorming):

• fix spec plugin (and global mountpoints) so that array keys get created
• separate mountpoints for every driver
• From top-post: "Setting the fallback metadata might also be a solution."
• Having some feature which automatically sets fallback metadata for all keys
• relying on defaults of high-level API (not so ideal as then kdb get does not show the correct values)

[kodebach]

fix spec plugin (and global mountpoints) so that array keys get created

I will look into this today. I hope it is not too big a change to just query the array metadata to find out which keys need to be created.

separate mountpoints for every driver

I thought about having separate specification, but that causes more problems than it solves. Also the problem is actually that the we have to support using the same driver with different configurations simultaneously. If we don't support that the problem goes away.

relying on defaults of high-level API

That doesn't work. Those defaults are even less powerful.

[markus2330]

I will look into this today. I hope it is not too big a change to just query the array metadata to find out which keys need to be created.

Thank you!

That doesn't work. Those defaults are even less powerful.

In which cases are they unable to return a default?

[kodebach]

The highlevel API simply inserts the passed defaults KeySet into the config KeySet that is used in the kdbGet call beforehand. So anything that isn't resolved via ksLookup doesn't work.

[kodebach]

I hope it is not too big a change to just query the array metadata to find out which keys need to be created.

Turns out it is a bigger change than expected. I now have a version that can handle # properly, but I need to fix a few other things now. Since the code was very confusing and the README didn't really explain a lot, I can however not guarantee that there won't be any breaking changes (outside what our tests catch).

Also, it will probably be much less efficient.

[markus2330]

Thank you for doing the changes even though it was much more work than expected.

Also, it will probably be much less efficient.

Better correct than fast. Hopefully only if # are used?