Types of KeySets

[kodebach]

The different types of KeySets should be made explicit. The types are:

1. "Normal" data: Keys of the namespaces proc:/, dir:/, user:/, system:/ and default:/ are allowed to be added to the KeySet. This is the default and what will be created by a simple ksNew.

2. Metdata: Only keys of namespace meta:/ are allowed. This type cannot be created via the public API. It is only created internally in a keyVNew call.

3. Cascading keys: Only cascading keys are allowed in these KeySets. This will be needed after Remove cascading key from cascading lookup order #3597 to still allow the use of KeySets as a general map-like data structure. This type of KeySet will be created via ksNewData (name open to suggestions).

---

Internally the type of KeySet will be determined by a flag in the struct _KeySet.

The public API could be made more intuitive by adding two typedefs: typedef KeySet MetaKeySet and typedef KeySet DataKeySet. These would be used for the return types of keyMeta and ksNewData respectively.

ksAppend, ksAppendKey and all other functions that modify the KeySet need to be updated to respect the new flag.

In addition to #3597 ksLookup has to modified to ignore the normal cascading lookup in Type 3 KeySets and instead lookup the cascading name directly.

[markus2330]

Thank you for creating the issue!

The public API could be made more intuitive by adding two typedefs: typedef KeySet MetaKeySet and typedef KeySet DataKeySet

DataKeySet sounds contradictory to its purpose as it is about Config, which can be defined as input of applications which is not domain-specific data. What about ConfigKeySet?

[kodebach]

DataKeySet sounds contradictory to its purpose as it is about Config, which can be defined as input of applications which is not domain-specific data. What about ConfigKeySet?

DataKeySet would be the one for general data that only allows cascading keys. The KeySets for config data (user:/, system:/ etc) would still just be KeySet.

[markus2330]

This type of KeySet is not used in the API anyway, so we also do not need to make this typedef.

[kodebach]

It would be the return type of the function proposed in point 3 above.

The basic idea would be that these work:

KeySet * ks = ksNew (1, keyNew ("user:/test", KEY_END), KS_END);
assert(ks != NULL);

DataKeySet * dks = ksNewData (1, keyNew ("/test", KEY_END), KS_END);
assert(dks != NULL);

But these will fail (= return NULL):

KeySet * ks = ksNew (2, keyNew ("/test", KEY_END), KS_END);
assert(ks == NULL);

DataKeySet * dks = ksNewData (1, keyNew ("user:/test", KEY_END), KS_END);
assert(dks == NULL);

The use of DataKeySet is just for clarity, what makes or breaks the code is ksNew vs ksNewData

[stale]

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 💖

[stale]

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 💖

[kodebach]

See also #4478

[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 💖