Uploaded image for project: 'Camunda Optimize'
  1. Camunda Optimize
  2. OPT-3241

Refactor how distributedByNone is handled

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: L3 - Default L3 - Default
    • 3.0.0-alpha2, 3.0.0
    • None
    • backend
    • 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:

      1. null keys are not allowed in the distributedByResults
      2. 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

            Helene Waechtler created issue -
            Helene Waechtler made changes -
            Description Original: *Context*:

            Currently(/once OPT-3197 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, 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 OPT-3197 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, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent.

            *Relevant code:*
             {{CompositeCommandResult.transformToMap()}}
             {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}}
            Helene Waechtler made changes -
            Mentioned Roles
            Helene Waechtler made changes -
            Mentioned Groups
            Helene Waechtler made changes -
            Description Original: *Context*:

            Currently(/once OPT-3197 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, 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 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, it would be good to refactor how we handle the {{distributedByNone}} case so that it is more consistent.

            *Relevant code:*
             {{CompositeCommandResult.transformToMap()}}
             {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}}
            Helene Waechtler made changes -
            Mentioned Roles
            Helene Waechtler made changes -
            Mentioned Groups
            Helene Waechtler made changes -
            Description Original: *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, 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 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.

             

            *Relevant code:*
             {{CompositeCommandResult.transformToMap()}}
             {{ProcessGroupByUserTask.addMissingGroupByBuckets(..)}}
            Helene Waechtler made changes -
            Mentioned Roles
            Helene Waechtler made changes -
            Mentioned Groups

              Unassigned Unassigned
              helene.waechtler Helene Waechtler
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: