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

Allow search for process definitions without versionTag

XMLWordPrintable

      Use case:
      I write a migration plan for my process instances.
      We did not set a versionTag in the beginning, so I have several old instances running with null for the version tag.
      The new target definition comes with version tag 1.

      To build a migration plan, I need the sourceProcessDefinitionIds of all instances running on a versionTag equal to null.

      However, I can not query for those definitions, because a query parameter null is not allowed for versionTag.

      Suggestion:
      Since having a null version tag is common, allow querying for it with a new query method withoutVersionTag.

        This is the controller panel for Smart Panels app

          1.
          		 In the Java API, I can search for process definitions without version tag Sub-task Closed Unassigned
          2.
          		 In the REST API, I can search for process definitions without version tag Sub-task Closed Unassigned

            [CAM-10852] Allow search for process definitions without versionTag

            Tobias Metzke-Bernstein added a comment -

            Hi jan.galinski@holisticon.de,

            thanks for the request.

            This sounds like a reasonable addition to the ProcessDefinitionQuery.
            I will rephrase the feature a little bit and go for adding an option that allows to search for definitions without versionTag rather than removing the null-check.
            I hope that is fine with you.

            As usual, if you would like to speed up the integration of that feature we are always happy about code contributions via pull requests.

            Thanks again.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hi jan.galinski@holisticon.de , thanks for the request. This sounds like a reasonable addition to the ProcessDefinitionQuery . I will rephrase the feature a little bit and go for adding an option that allows to search for definitions without versionTag rather than removing the null-check. I hope that is fine with you. As usual, if you would like to speed up the integration of that feature we are always happy about code contributions via pull requests. Thanks again. Best, Tobias

            Jan Galinski added a comment -

            Hi Tobias, thanks for accepting the request. If we agree on a solution, I can help out via PR ...

            I personally do not like extending the fluent usage idea. Currently I wrapped the query in a method:

            Set<String> findProcessDefinitionIdsByVersion(String versionTag)

            { // here be the query that finds all procDefIds for a given process and versionTag }

            If null remains an illegal parameter for the queryBuilder, I have to interupt the fluent usage, manually do a null check and decide whether I want to continue with one of the versionTag options ..

            I would prefer to just put a valid versionTag into the query (and null seems to be a valid versionTag) and let "the framework" (aka camunda) deal with the decision.
            Understandable?

            Jan Galinski added a comment - Hi Tobias, thanks for accepting the request. If we agree on a solution, I can help out via PR ... I personally do not like extending the fluent usage idea. Currently I wrapped the query in a method: Set<String> findProcessDefinitionIdsByVersion(String versionTag) { // here be the query that finds all procDefIds for a given process and versionTag } If null remains an illegal parameter for the queryBuilder, I have to interupt the fluent usage, manually do a null check and decide whether I want to continue with one of the versionTag options .. I would prefer to just put a valid versionTag into the query (and null seems to be a valid versionTag) and let "the framework" (aka camunda) deal with the decision. Understandable?

            Tobias Metzke-Bernstein added a comment -

            Hi Jan,

            thanks for your quick reply and the input.

            I agree that it would be easier in this case to have the framework deal with the null input itself.

            There are however other factors that need to be considered as well when adjusting the Query API:

            1. We strive to provide a consistent API here and the pattern for null parameters used so far is adding explicit withoutXYZ options. We consider this consistency a valuable asset and would not want to break it for this case.
            2. In order to expose this option in the REST API as well, we prefer the unambiguous way of having an explicit null option rather than trying to identify if the attribute with a null value is meant as not being set in the query DTO or being intentionally set to null.

            Adding an explicit withoutVersionTag option here in the ProcessDefinitionQuery therefore would be our preferred solution in the Java and REST APIs.
            I hope that those are plausible reasons for you as well and that you can agree with the proposed solution.
            Thanks for offering your help on this, this is very much appreciated.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hi Jan, thanks for your quick reply and the input. I agree that it would be easier in this case to have the framework deal with the null input itself. There are however other factors that need to be considered as well when adjusting the Query API: We strive to provide a consistent API here and the pattern for null parameters used so far is adding explicit withoutXYZ options. We consider this consistency a valuable asset and would not want to break it for this case. In order to expose this option in the REST API as well, we prefer the unambiguous way of having an explicit null option rather than trying to identify if the attribute with a null value is meant as not being set in the query DTO or being intentionally set to null . Adding an explicit withoutVersionTag option here in the ProcessDefinitionQuery therefore would be our preferred solution in the Java and REST APIs. I hope that those are plausible reasons for you as well and that you can agree with the proposed solution. Thanks for offering your help on this, this is very much appreciated. Best, Tobias

            Jan Galinski added a comment -

            Ah, ok, I see ... in that case: everything is better than than "get all and filter manually" so, I am looking forward to your solution ...

            Jan Galinski added a comment - Ah, ok, I see ... in that case: everything is better than than "get all and filter manually" so, I am looking forward to your solution ...

              Unassigned Unassigned
              jan.galinski@holisticon.de Jan Galinski
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: