I found a behaviour that I may not classify as bug, but that creates quite a bit of headaches in certain situations.
The problem arises when querying (process) Executions and checking for specific variable values. Especially with all Number and relative primitive types.
Scenario is this:
- I start a process
- the process (in a service task) will set a certain variable (say "varName") to a Long (as in java.lang.Long) value of (say) 12345.
- later I receive an external "something" that requires me to pick the process(es) which have such varName variable with 12345 value.
-> this "something" will actually be the result of a JSON deserialization into a generic Map (I can't use a value object as I should be flexible enough to work with value objects that may evolve and I don't want to/can't have hard dependencies to other systems in my software)
Now the problem: the JSON serializer (Jackson actually, but I think others may do the same), when not forced to match a particular type will choose the "right sized" java type based on the value received, like this
numbers <= 2^31-1 –> java.lang.Integer
numbers >= 2^31 –> java.lang.Long
(think it may also use BigInteger when appropriate, and the same widening will happen with Float, Double and BigDecimal even though I haven't tested it)
I think you easily see when this is going.
When receiving such 12345 value, it will be Integer and ExecutionQueryBuilder.processVariableValueEquals("varName", 12345) will result in the lookup of an variable on the ACT_RU_VARIABLE with TYPE = "integer" and LONG = 12345, resulting in no process picked up.
As I was saying, this is not a bug, but a corner case behaviour, that requires some choices (we "banned" the use of Integers and Floats on execution.setVariable()).
Point is that the ACT_RU_VARIABLE uses the same column (LONG) for Integer/Long and another (DOUBLE) for Float/Double, while having 4 different values for the TYPE column (integer, long, float, double), resulting in possible mismatches when these "uncontrollable conversions" happen.
Wouldn't it be simpler to use the same TYPE value for the couples Long/Integer and Float/Double (yes, it may screw up the unmarshalling) or else not checking the type for the numeric types?
