-
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
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