Extend-able QueryParameters for Query API

[balsarori]

Hi

Activiti's Query API fulfills most of my query requirements with some simple exceptions such as querying tasks that are assigned (assignee is not null) and querying tasks/processInstances that a user is involved in with a specific involvement type (ie kermit involved as manager).

I think that the requirements are too simple for using native queries. It would be great if the Query API provided a way to add extra query parameters. Maybe one way to achieve this is by separating parameters from the Query classes for example, moving TaskQuery parameters into a class TaskQueryParameters which holds query parameters and can be extended and passed to TaskQuery. Creating an instance of TaskQuery with a custom TaskQueryParameters can be by calling

[java]
taskService.createTaskQuery(TaskQueryParameters taskQueryParameters)
[/java]

In XML parameters can be used like this

      <if test="taskParams.assigned">
        and RES.ASSIGNEE_ IS NOT NULL
      </if>
‍‍‍‍‍

The same can be applied to other Query classes. Users that want to do simple query modifications and/or additions can achieve this by extending QueryParameters without having to write native queries.

Will this be of any value?

[frederikherema1]

The main issue is that it's not always a straight-forward 'is null' or '= value' check for the most parameters supported right now. If we whould need to adapt all existing queries, this will have a huge impact on everything and needs thorough testing. We don't have the bandwidth for this right now, so don't think this will happen any time soon.

If you feel some query-options are missing (like the taskAssigned() one, which makes sense) you're free to create a pull-request for this. We're always happy to accept contributions

[balsarori]

Thanks for your response.

You may be right. How about just adding the ability to add custom parameters simply by just adding an optional params property (of interface i.e. QueryParameters) to AbstractQuery class

The custom parameters will not be supported directly by Query API instead users will need to add appropriate SQL checks by modifying XML mapping files.

Kindly check my initial modifications
https://github.com/balsarori/Activiti/compare/queryparams

If you agree, I'll apply the modifications to the rest of Query classes and create a pull request.

[frederikherema1]

I guess the need to change the mapping XML-files in order to use something that is offered in our API is a no-go. In case people alter the mapping-xml's, they need to fork activiti anyway and they might end up with incompatible changes in regards to future versions in the XML…

The solution makes sense for some people, but we can't include it in the API if it's not doing anything without a custom version of Activti. That's the reason we added the native queries, to prevent this…

[balsarori]

Writing native queries can result in the same issue. Users will have to update their native queries when future Activiti versions that include schema modifications. Not to mention the complexity of writing native queries which are not typesafe. Users will end up writing poor code with hard coded SQL statements separated in different parts of their code or building their own Query API (build on the Native Query API) or forking the Query API and it's implementation (java files and XML files) to add the modifications they need. Updating an XML file or two that may contain few modified lines with a new version could be a much more simpler option.

At the end, I think the user should be given options to choose between what they think is better for them as long as the drawbacks of each option is clearly mentioned.

Anyway, I have added some query options to the TaskQuery in this pull request
https://github.com/Activiti/Activiti/pull/346

[frederikherema1]

I get the point - we can't cater for all query possibilities (downside of writing own SQL-mapping for better control, opposed to exposing eg. a JPA Criteria API). Again, it's not ideal but we DON'T want an API that forces you to fork the engine to alter XML-mapping files. If we whould offer a way of hooking in additional XML-mapping files in mybatis using the process-engine configuration, this is another story. At the moment, we don't have the bandwidth to do a change of this magnitude, I'm afraid…

I'll take a look at the pull-request, thanks!

[balsarori]

Hi @frederikheremans,
Its been a while since the last discussion of this issue. I did not give up yet

I've made simple changes to process-engine configuration that enables setting custom mybatis XML mapping files. I also added some tests that use a custom xml mapping file and a custom task query. Please check it out

https://github.com/balsarori/Activiti/commit/812c5bab083a89796490133957139433da7f659b