Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-7435

I can get the process definition version from historic process instance

    Details

    • Type: Feature Request
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.7.0, 7.7.0-alpha2
    • Component/s: engine
    • Labels:

      Description

      AT:

      • when querying for historic process instances I must receive back Process definition key, Process definition version and Process definition name
      • I can sort on these fields

        Issue Links

          Activity

          Hide
          svetlana.dorokhova Svetlana Dorokhova added a comment -

          Following requests must be updated:

          Get List
          GET /history/process-instance
          Get List (POST)
          POST /history/process-instance

          This can also be affected:

          Get
          GET /history/process-instance/

          Unknown macro: {id}
          Show
          svetlana.dorokhova Svetlana Dorokhova added a comment - Following requests must be updated: Get List GET /history/process-instance Get List (POST) POST /history/process-instance This can also be affected: Get GET /history/process-instance/ Unknown macro: {id}
          Hide
          svetlana.dorokhova Svetlana Dorokhova added a comment -

          Philipp Ossler, could you please review the changes?

          Show
          svetlana.dorokhova Svetlana Dorokhova added a comment - Philipp Ossler , could you please review the changes?
          Hide
          svetlana.dorokhova Svetlana Dorokhova added a comment -

          After the test for sorting process instances was extended by real sorting verification (ProcessInstanceQueryTest), it started failing on PostgreSQL and SQL Server databases. Results of investigation:

          1. our test databases use slightly different collation rules (e.g. comparing of strings "oneTaskProcess:1:104" and "oneTaskProcess2:1:105" gave different results on MySQL and PostgreSQL) Checked with Christian Lipphardt
          2. Testing for sorting using TestOrderingUtil#verifySorting is not fully correct as it compares Java String sorting (lexicographical) with DB sorting, which ideally takes into account Locale settings. We can at least replace basic object comparison with Collator.getInstance().compare(o1,o2), but we must be sure that all test databases use the same collation settings.
          3. Many tests for sorting queries results do not really test sorting. They look like this:
                assertEquals(5, runtimeService.createProcessInstanceQuery().orderByProcessInstanceId().desc().list().size());
                assertEquals(5, runtimeService.createProcessInstanceQuery().orderByProcessDefinitionId().desc().list().size());
                assertEquals(5, runtimeService.createProcessInstanceQuery().orderByProcessDefinitionKey().desc().list().size());
            

            Probably we don't need them at all?

          Show
          svetlana.dorokhova Svetlana Dorokhova added a comment - After the test for sorting process instances was extended by real sorting verification (ProcessInstanceQueryTest), it started failing on PostgreSQL and SQL Server databases. Results of investigation: our test databases use slightly different collation rules (e.g. comparing of strings "oneTaskProcess:1:104" and "oneTaskProcess2:1:105" gave different results on MySQL and PostgreSQL) Checked with Christian Lipphardt Testing for sorting using TestOrderingUtil#verifySorting is not fully correct as it compares Java String sorting (lexicographical) with DB sorting, which ideally takes into account Locale settings. We can at least replace basic object comparison with Collator.getInstance().compare(o1,o2), but we must be sure that all test databases use the same collation settings. Many tests for sorting queries results do not really test sorting. They look like this: assertEquals(5, runtimeService.createProcessInstanceQuery().orderByProcessInstanceId().desc().list().size()); assertEquals(5, runtimeService.createProcessInstanceQuery().orderByProcessDefinitionId().desc().list().size()); assertEquals(5, runtimeService.createProcessInstanceQuery().orderByProcessDefinitionKey().desc().list().size()); Probably we don't need them at all?
          Hide
          svetlana.dorokhova Svetlana Dorokhova added a comment -

          Fixes for the review items are committed.

          Show
          svetlana.dorokhova Svetlana Dorokhova added a comment - Fixes for the review items are committed.
          Hide
          mariusz.sielski Mariusz Sielski added a comment -

          As we discussed sortable columns should be named processDefinitionId, processDefinitionKey and processDefinitionName

          Show
          mariusz.sielski Mariusz Sielski added a comment - As we discussed sortable columns should be named processDefinitionId, processDefinitionKey and processDefinitionName
          Hide
          svetlana.dorokhova Svetlana Dorokhova added a comment -

          definitionId can not be changed on processDefinitionId, as it exists from 2013. Decided not to change the others also.

          Also checked the docs: all parameters are documented here https://stage.docs.camunda.org/manual/develop/reference/rest/history/process-instance/get-process-instance-query/

          Show
          svetlana.dorokhova Svetlana Dorokhova added a comment - definitionId can not be changed on processDefinitionId, as it exists from 2013. Decided not to change the others also. Also checked the docs: all parameters are documented here https://stage.docs.camunda.org/manual/develop/reference/rest/history/process-instance/get-process-instance-query/

            People

            • Assignee:
              svetlana.dorokhova Svetlana Dorokhova
              Reporter:
              svetlana.dorokhova Svetlana Dorokhova
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: