[new-backend] spec hook - default:/ backend

[atmaxinger]

I've got the spec plugin and its copy hook in a state where it will generate the default:/ keys according to spec.
However, backendsDivide fails because there is no backend for default:/ keys.

Command:
kdb meta-get spec:/example/port default

spec.ini:

[port]
meta:/default = 8080

Expected result:
8080

Actual result:

Sorry, module kdb issued the error C01310:
Internal: Couldn't divide keys into mountpoints before poststorage. Please report this bug at https://issues.libelektra.org.

@kodebach can we just add a backend that is responsible for default:/ keys? Or can we somehow prevent default:/ keys from being passed to backendsDivide, but so that they are still part of the resulting keyset?

[atmaxinger]

I worked around it by cutting all default:/ keys before the split and then merging them in into the end result.
As there is no backend involved, it should be fine if they are not contained in the post storage phase (?).

Key * defaultCutpoint = keyNew ("default:/", KEY_END);
KeySet * defaults = ksCut (dataKs, defaultCutpoint);

// backendDivide
// other phases
// backendMerge

ksAppend (ks, defaults);
ksDel (defaults);
keyDel(defaultCutpoint);

[kodebach]

As there is no backend involved, it should be fine if they are not contained in the post storage phase (?).

As written in the docs (doc/dev/kdb-operations.md) backends for default:/ are possible (not sure if they would work right now). This needed to run validation like the type plugin on default:/ keys created by spec.

So the cutting and re-adding might work now, but it is not a permanent solution. Instead we should probably create a default:/ backend for every spec:/ backend.

[markus2330]

So we should mount a backend containing type per default as default:/ backend?

[kodebach]

I don't know. Wouldn't that just raise questions why type is added by default to default:/ but not other namespaces?

[markus2330]

I think type should be added by default to all the namespaces, see #690

[kodebach]

With #4187 it would ultimately be the responsibility of a backend plugin to call type. "Added by default" in this context just means, "call type even if the user didn't configure it". There are also exceptions like specload (see #4444) which obviously shouldn't call type. In fact calling type on `spec:/ keys doesn't make sense in general.

I don't think this "added by default" approach is feasible. However, there is another option: Make type (also) a hook plugin, in which case libelektra-kdb could call the hook directly.

I think we could just call type after the poststorage phase in get and before prestorage in set. That way we'd only validate the actual data used within the application. To allow configuring type for individual mountpoints (e.g. with custom boolean values), it would still be possible to add type to a mountpoint when needed (*). The hook-instance of type should also be configured to do only validation, but no normalization. If you need normalization, you must add type to the mountpoint that needs it.

This would make it so that by default (when libelektra-type is installed), the meta:/type of all keys is validated. Applications could rely on the fact that a key with meta:/key, which was returned by kdbGet, will always contain a value valid for that type.

(*) kdb spec-mount would need special code to avoid mounting type unnecessarily.

[github-actions]

I mark this 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 by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions 💖

[github-actions]

I closed this 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 💖