cancel
Showing results for 
Search instead for 
Did you mean: 

Variable query problem

vladg90
Champ in-the-making
Champ in-the-making
Hi,

I am upgrading from Activiti 5.11 to 5.13 and I have the following problem:
I am using the REST API. In actu_ru_variable and acti_hi_varinst tables, column var_type_  the values for new
process instances that used to be long with Activiti 5.11 are now set as integer, regardless of the form properties
set in workflow definitions. That wouldn't be much of a problem but when I'm querying for process instances using
variable query without specifying the variable type the old process instances(where the values were set as long)
are not found because the querying variable value falls into integer type.
As a workaround I explicitly set the type of starting process instance variables to long in order to do a single query
instead of one for each type (integer and long).

The question is: why is this differentiation between integer and long for query implementation, though the values
are stored in the same column (long_) in the database?

Thanks & Regards,
Vlad








3 REPLIES 3

trademak
Star Contributor
Star Contributor
Hi,

In the variable query the type is also checked. So although the value is stored in the same column the type is different for integer and long. But I agree that there's room for improvement there. Could you create a JIRA issue for this?

Best regards,

vladg90
Champ in-the-making
Champ in-the-making
Hi,

I created the JIRA issue: http://jira.codehaus.org/browse/ACT-1787

Thanks & Regards,
Vlad

frederikherema1
Star Contributor
Star Contributor
I don't really agree with leaving out the type-check. With custom variables types (eg. JPAVariable) the long-column (and other columns) can also be used. If the long-column is used by a custom variable, it's possible that the values stored in there don't correspond to an actual "long" or "int" value, rather are an ID of a referenced entity. So leaving out the type-comparison could introduce issues with these kind of variables.
Also, this whould also falsely report results, in case you query for "0" and "1" values, in relation to booleans, which also use a numeric representation in the database.