Property Setters don't deduplicate in dict or list case #3211
Comments
|
So since the linked PR shows that this problem is more complex than I thought, I will write down the problem to find a solution hopefully. Problem: When utilizing setters in our items it can happen that "raw" values contain duplicated content. This may lead to problems with retrieving the correct resolved value. Data types that are affected by this:
Tackling the first problem: list Inheritance with list works that we combine all the lists from all raw item values. This is a recursive operation. We have no special syntax that removes entries (in contract to dict). We also don't have a way to keep track of the order things are blended together. The keys that are of type list atm don't depend on the order of the entries in a list and as such this is not a big problem. To deduplicate this correctly we just ask the parent object for its resolved value and remove all those entries in our list. The resulting list must be our new raw value. This behaviour can be easily ensured via testing. Tackling the second problem: dict Inheritance with dict works that we combine all the dicts from all the raw items. This is a recursive operation. We do want to remove keys in our dict that start with an exclamation mark. We don't have a way to keep track of the order of things are blended together. Since the blended dict doesn't contain the key removals via the exclamation mark anymore this operation is a bit harder. Furthermore, values may be overridden by children. Atm we cannot handle correctly that a key is mentioned multiple times but so far it seems that this is not required by users (even though it may happen in the kernel options that this is needed). Furthermore, it is unintuitive that users cannot directly update the dictionary that is returned to them via the property. I think this should be an orthogonal problem. Using the strategy from the list we gain a good approximation of what we want but it could be that it doesn't work as desired. Intermediate result of my thoughts: It seems that somewhere in this thought process I have a logic error because that is precisely what was implemented in the linked PR. However, the testsuite is showing me a lot of errors that I cannot explain myself atm. |
|
After fixing the bug in the linked PR I discovered that it appears that the only inheritance that the This smaller scope means that no deduplication for lists needs to be performed and resolving them only is done with a value takeover. |
Describe the bug
When using a setter like
item.kernel_options, the setter is assuming that you pass it a raw value. However if the data is retrieved before viaitem.kernel_optionsthe data returned is resolved. This leads to data duplication inside Cobbler.Steps to reproduce
my_value = item.kernel_optionsitem.kernel_options = my_valueExpected behavior
The data that is attached to the parent(s) is not duplicated in the children.
Cobbler version
Operating system
Cobbler log
Screenshots
Additional information
This can be fixed with logic that is already present in
CobblerAPI.set_item_resolved_value.The text was updated successfully, but these errors were encountered: