yes, it will be using named parameters as well. I have not done that yet completely. Just wanted to gather some feedback if the idea make sense
Since I tried to make it quite generic, compared to having new methods for every parameter, I want to make sure it suits others too before continuing with it.
uploaded new patch to jira. Please let me know if you have any further comments or shall I continue and provide similar way for all queries.
Finally I am done with implementation work for this issue, it covers all queries plus requested change to use hibernate way of applying parameters to the query.
Supported SQL operands are:
- Not in
Please have a look at latest patch (JBPM-2873-final.patch) and let me know what do you think about it.
In the end I decided to change it a bit and provide overloaded method for each available parameter that allows to provide operand for the query instead of having one method that sets the operand prior to setting the parameter. This way is more intuitive and in line with current implementation.
After adding the new history columns introduced in JBPM-2398 to the create/drop schema scripts and reviewing the QueryOperand use, I am not very comfortable with the fact that the parameter value has to be a String, even if operands such as IN should be taking a List. I'd much rather have a factory for restrictions that can be added to queries much like the Hibernate criteria API
On the other hand, when reaching this level of flexibility one begins to wonder why not just skip the jBPM queries entirely and go straight to the far more expressive Hibernate criteria. Anyways, I will reopen JBPM-2873 and work on this proposal.
Alternative solution to keep it quite simple could be to change the method signature to switch parameters:
HistoryProcessInstanceQuery processInstanceId(QueryOperand operand, String... processInstanceId);
such a change will make it more intuitive if it comes to list base operands (in, not it) but will not require too much of work and changes in the API. In addition based on such method signature we could validate if parameters are in correct format.
Introducing hibernate criteria could be too big step, in my opinion especially when there is jBPM5 on the way.
What do you think about it?
Alternative solution to keep it quite simple could be to change the method signature to switch parameters
This is certainly a nicer solution as it allows the client to pass as many parameters as the operator takes without concatenation. I applied the change to the codebase and it seems like a good compromise between simplicity and expresiveness.
jbpm4.5 what time release?