Libelektra: Possible bug in kdbGet
@markus2330 I think there might be a bug in kdbGet related to global plugins:
As you can see, elektraGetDoUpdate is called with parentKey, which is then modified by this function. Later on elektraGlobalGet is called with this parentKey. But if I understand correctly how global plugins should work, the key name should be reset to initalParent beforehand not afterwards (line 903).
kodebach
All 7 comments
Thank you for reporting this problem!
@mpranj Is this something you will change within your PR?
markus2330
on 14 Mar 2019
This has not changed within my current cache PR.
The global plugins are not fully implemented, so there are definitely even more bugs. To my knowledge the parentKey should not even be initialParent, but actually the name should contain the global position. That way, the global plugins would know where they are currently called from.
mpranj
on 14 Mar 2019
@mpranj Thank you for looking into it. We are already waiting for your implementation of the global plugins :+1:
@kodebach do you have a concrete situation where this creates a problem? Is a fix urgent?
markus2330
on 14 Mar 2019
I was looking into it because of the options plugin. As discussed, ideally we would add a placement procgetstorage between getstorage and postgetstorage which would be used for plugins that write to the proc namespace.
This is also relevant for caching, because those plugin would always have to be executed (if kdbGet is called twice in the same process, we could skip some plugins, e.g. the options plugin).
The options plugin has to know the parent key of the current applications specification. Normally this is the parent key passed to kdbGet. This is why I was looking at what parent key is passed to global plugins, because normal plugins obviously get the parent of their mountpoint not what is passed to kdbGet.
kodebach
on 14 Mar 2019
Considering the current state of the implementation I am absolutely open to suggestions.
I think it might even make sense to put more information in the parentKey for global plugins. We can keep the initialParent as parentKey and add the position and other information as meta-keys.
Another option is to exchange additional information via the global keyset.
mpranj
on 14 Mar 2019
@kodebach I think you resolved this problem by implementing the PROCGETSTORAGE position. Can we close this?
mpranj
on 8 Apr 2020
I don't remember who initially fixed it, but this line fixes the problem:
kodebach
on 9 Apr 2020
Related issues
sanssecours
路
57Comments
KurtMi
路
85Comments
markus2330
路
62Comments
ingwinlu
路
35Comments
markus2330
路
49Comments
Most helpful comment
I was looking into it because of the options plugin. As discussed, ideally we would add a placement
procgetstoragebetweengetstorageandpostgetstoragewhich would be used for plugins that write to theprocnamespace.This is also relevant for caching, because those plugin would always have to be executed (if
kdbGetis called twice in the same process, we could skip some plugins, e.g. the options plugin).The options plugin has to know the parent key of the current applications specification. Normally this is the parent key passed to
kdbGet. This is why I was looking at what parent key is passed to global plugins, because normal plugins obviously get the parent of their mountpoint not what is passed tokdbGet.