-
Task
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
Context:
Currently(/once OPT-3170 is done), when retrieving results of our GroupByParts (e.g. in ProcessGroupByUserTask ), if the result is distributedByNone, the value of each groupByResult is nested in one single distributedByResult. This is then mapped to a ReportMapResultDto, which expects exactly one distributedByResult out of which it extracts the value and adds it to the map with the appropriate groupByKey.
This leads to the following, which is quite unintuitive:
If we need to add empty groupByResults (e.g. for userTasks in ProcessGroupByUserTask that have not been executed yet) and the result is distributedByNone, we create a groupByResult with the appropriate key and a distributedByResult with all null properties. This is then transformed to a `0` value in the ReportMapResultDto.
However, if we have any other distributedBy (not none), the results will not be mapped to a map but to a HyperMap. This means:
- null keys are not allowed in the distributedByResults
- we might need more than one distributedByResult (so that all groupByResults have the same distributedByResult keys
For that reason, we currently differentiate between having distributedByNone and distributedBySomething - if it is the first, we add one all null distributedByResult and if it is the latter, we first add an empty List of distributedByResults which is then in a second step filled with the appropriate distributedByResults which have the correct keys but a null value.
This behaviour is a bit unintuitive, if possible it would be good to refactor how we handle the distributedByNone case so that it is more consistent. Alternatively, the behaviour needs at least moved to a more generalised location, so that it is more obvious what's required when adding new distributedBy features to groupBys which so far have no distributedBy options.
Relevant code:
CompositeCommandResult.transformToMap()
ProcessGroupByUserTask.addMissingGroupByBuckets(..)
This is the controller panel for Smart Panels app
[OPT-3241] Refactor how distributedByNone is handled
Description |
Original:
*Context*:
Currently(/once This leads to the following, which is quite unintuitive: If we need to add empty {{groupByResults}} (e.g. for userTasks in {[ProcessGroupByUserTask}} that have not been executed yet) and the result is {{distributedByNone}}, we create a groupByResult with the appropriate key and a {{distributedByResult}} with all null properties. This is then transformed to a `0` value in the {{ReportMapResultDto}}. However, if we have any other {{distributedBy}} (not none), the results will not be mapped to a map but to a HyperMap. This means: # {{null}} keys are not allowed in the {{distributedByResults}} # we might need more than one {{distributedByResult}} (so that all {{groupByResults}} have the same {{distributedByResult}} keys For that reason, we currently differentiate between having {{distributedByNone}} and {{distributedBySomething}} - if it is the first, we add one all null {{distributedByResult}} and if it is the latter, we first add an empty List of {{distributedByResults}} which is then in a second step filled with the appropriate {{distributedByResults}} which have the correct keys but a null value. This behaviour is a bit unintuitive, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent. *Relevant code: * {{CompositeCommandResult.transformToMap()}} {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}} |
New:
*Context*:
Currently(/once This leads to the following, which is quite unintuitive: If we need to add empty {{groupByResults}} (e.g. for userTasks in \{[ProcessGroupByUserTask}} that have not been executed yet) and the result is {{distributedByNone}}, we create a groupByResult with the appropriate key and a {{distributedByResult}} with all null properties. This is then transformed to a `0` value in the {{ReportMapResultDto}}. However, if we have any other {{distributedBy}} (not none), the results will not be mapped to a map but to a HyperMap. This means: # {{null}} keys are not allowed in the {{distributedByResults}} # we might need more than one {{distributedByResult}} (so that all {{groupByResults}} have the same {{distributedByResult}} keys For that reason, we currently differentiate between having {{distributedByNone}} and {{distributedBySomething}} - if it is the first, we add one all null {{distributedByResult}} and if it is the latter, we first add an empty List of {{distributedByResults}} which is then in a second step filled with the appropriate {{distributedByResults}} which have the correct keys but a null value. This behaviour is a bit unintuitive, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent. *Relevant code:* {{CompositeCommandResult.transformToMap()}} {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}} |
Mentioned Roles |
Mentioned Groups |
Description |
Original:
*Context*:
Currently(/once This leads to the following, which is quite unintuitive: If we need to add empty {{groupByResults}} (e.g. for userTasks in \{[ProcessGroupByUserTask}} that have not been executed yet) and the result is {{distributedByNone}}, we create a groupByResult with the appropriate key and a {{distributedByResult}} with all null properties. This is then transformed to a `0` value in the {{ReportMapResultDto}}. However, if we have any other {{distributedBy}} (not none), the results will not be mapped to a map but to a HyperMap. This means: # {{null}} keys are not allowed in the {{distributedByResults}} # we might need more than one {{distributedByResult}} (so that all {{groupByResults}} have the same {{distributedByResult}} keys For that reason, we currently differentiate between having {{distributedByNone}} and {{distributedBySomething}} - if it is the first, we add one all null {{distributedByResult}} and if it is the latter, we first add an empty List of {{distributedByResults}} which is then in a second step filled with the appropriate {{distributedByResults}} which have the correct keys but a null value. This behaviour is a bit unintuitive, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent. *Relevant code:* {{CompositeCommandResult.transformToMap()}} {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}} |
New:
*Context*:
Currently(/once This leads to the following, which is quite unintuitive: If we need to add empty {{groupByResults}} (e.g. for userTasks in \{[ProcessGroupByUserTask}} that have not been executed yet) and the result is {{distributedByNone}}, we create a groupByResult with the appropriate key and a {{distributedByResult}} with all null properties. This is then transformed to a `0` value in the {{ReportMapResultDto}}. However, if we have any other {{distributedBy}} (not none), the results will not be mapped to a map but to a HyperMap. This means: # {{null}} keys are not allowed in the {{distributedByResults}} # we might need more than one {{distributedByResult}} (so that all {{groupByResults}} have the same {{distributedByResult}} keys For that reason, we currently differentiate between having {{distributedByNone}} and {{distributedBySomething}} - if it is the first, we add one all null {{distributedByResult}} and if it is the latter, we first add an empty List of {{distributedByResults}} which is then in a second step filled with the appropriate {{distributedByResults}} which have the correct keys but a null value. This behaviour is a bit unintuitive, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent. *Relevant code:* {{CompositeCommandResult.transformToMap()}} {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}} |
Mentioned Roles |
Mentioned Groups |
Description |
Original:
*Context*:
Currently(/once This leads to the following, which is quite unintuitive: If we need to add empty {{groupByResults}} (e.g. for userTasks in \{[ProcessGroupByUserTask}} that have not been executed yet) and the result is {{distributedByNone}}, we create a groupByResult with the appropriate key and a {{distributedByResult}} with all null properties. This is then transformed to a `0` value in the {{ReportMapResultDto}}. However, if we have any other {{distributedBy}} (not none), the results will not be mapped to a map but to a HyperMap. This means: # {{null}} keys are not allowed in the {{distributedByResults}} # we might need more than one {{distributedByResult}} (so that all {{groupByResults}} have the same {{distributedByResult}} keys For that reason, we currently differentiate between having {{distributedByNone}} and {{distributedBySomething}} - if it is the first, we add one all null {{distributedByResult}} and if it is the latter, we first add an empty List of {{distributedByResults}} which is then in a second step filled with the appropriate {{distributedByResults}} which have the correct keys but a null value. This behaviour is a bit unintuitive, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent. *Relevant code:* {{CompositeCommandResult.transformToMap()}} {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}} |
New:
*Context*:
Currently(/once This leads to the following, which is quite unintuitive: If we need to add empty {{groupByResults}} (e.g. for userTasks in \{[ProcessGroupByUserTask}} that have not been executed yet) and the result is {{distributedByNone}}, we create a groupByResult with the appropriate key and a {{distributedByResult}} with all null properties. This is then transformed to a `0` value in the {{ReportMapResultDto}}. However, if we have any other {{distributedBy}} (not none), the results will not be mapped to a map but to a HyperMap. This means: # {{null}} keys are not allowed in the {{distributedByResults}} # we might need more than one {{distributedByResult}} (so that all {{groupByResults}} have the same {{distributedByResult}} keys For that reason, we currently differentiate between having {{distributedByNone}} and {{distributedBySomething}} - if it is the first, we add one all null {{distributedByResult}} and if it is the latter, we first add an empty List of {{distributedByResults}} which is then in a second step filled with the appropriate {{distributedByResults}} which have the correct keys but a null value. This behaviour is a bit unintuitive, _if possible_ it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent. *Relevant code:* {{CompositeCommandResult.transformToMap()}} {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}} |
Mentioned Roles |
Mentioned Groups |