-
Feature Request
-
Resolution: Won't Do
-
L3 - Default
-
None
-
None
-
None
User Story (Required on creation):
Just notice that the various xxxQuery objects exposed in the RuntimeService and the RepositoryService (I haven't checked all of them) are all over the place
VariableInstanceQuery processInstanceIdIn(String... processInstanceIds);
and
ProcessDefinitionQuery processDefinitionIdIn(String... ids);
vs
ProcessInstanceQuery processInstanceIds(Set<String> processInstanceIds);
So, in order to find all process definitions for a "collection" of process instance IDs, I need a java.util.Set, but to find all deployments from which those definitions came, I need a String array.
Then, to delete multiple process instances, I need a java.util.List.
All this could be a little more consistent to make the code I use to interact with that API a bit less "hacky".
Functional Requirements (Required before implementation):
No new functionality required
Technical Requirements (Required before implementation):
Limitations of Scope (Optional):
Hints (optional):
This is the controller panel for Smart Panels app
[CAM-14211] Make the various Query classes more consistent in their APIs
| Description |
Original:
h3. User Story (Required on creation):
Just notice that the various xxxQuery objects exposed in the RuntimeService and the RepositoryService (I haven't checked all of them) are all over the place VariableInstanceQuery processInstanceIdIn(String... processInstanceIds); and ProcessDefinitionQuery processDefinitionIdIn(String... ids); vs ProcessInstanceQuery processInstanceIds(Set<String> processInstanceIds); h3. Functional Requirements (Required before implementation): No new functionality required h3. Technical Requirements (Required before implementation): h3. Limitations of Scope (Optional): h3. Hints (optional): |
New:
h3. User Story (Required on creation):
Just notice that the various xxxQuery objects exposed in the RuntimeService and the RepositoryService (I haven't checked all of them) are all over the place VariableInstanceQuery processInstanceIdIn(String... processInstanceIds); and ProcessDefinitionQuery processDefinitionIdIn(String... ids); vs ProcessInstanceQuery processInstanceIds(Set<String> processInstanceIds); So, in order to find all process definitions for a "collection" of process instance IDs, I need a java.util.Set, but to find all deployments from which those definitions came, I need a String array. Then, to delete multiple process instances, I need a java.util.List. All this could be a little more consistent to make the code I use to interact with that API a bit less "hacky". h3. Functional Requirements (Required before implementation): No new functionality required h3. Technical Requirements (Required before implementation): h3. Limitations of Scope (Optional): h3. Hints (optional): |
| Mentioned Roles |
| Mentioned Groups |
| Mentioned Roles |
| Mentioned Groups |
| Assignee | New: Miklas Boskamp [ miklas.boskamp ] |
| Resolution | New: Won't Do [ 10101 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
| Mentioned Roles |
| Mentioned Groups |
Hi Gwaptiva,
Thanks for sharing your feedback. I certainly can see that handling those different parameter types can get annoying.
Those APIs grew over time with a lot of people working on them. We usually strive to be consistent within one query object (e.g., ProcessInstanceQuery).
We need to maintain backwards compatibility with our products so removing any of the already existing API methods is not an option.
The only thing we could do is to provide a method for each parameter type for all queries. But this would certainly bloat the API and would not help understanding it.
In conclusion, it is a valid suggestion to make the APIs consistent but unfortunately, it is not feasible.
Best,
Miklas