iBetweenInclusive: java.lang.String cannot be cast to java.lang.Long

[stonebranch2]

Hi Isomorphic,

If would appear that if we have a defaultValue defined in the DS for an integer field, when creating filters, the between (inclusive) generates a String "0" start value instead of a numeric 0 start value. We don't have the problem for equals.


SmartClient Version: v10.1p_2017-01-17/Pro Deployment (built 2017-01-17)

        <field name="retryMaximum" type="integer" defaultValue="0"</field>

This causes a ClassCastException.

java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Long
    at com.isomorphic.criteria.RangeOperator.parseCriterion(RangeOperator.java:81)
    at com.isomorphic.criteria.Evaluator.parseCriterion(Evaluator.java:226)
    at com.isomorphic.criteria.OperatorBase.parseCriterion(OperatorBase.java:66)
    at com.isomorphic.criteria.Evaluator.parseCriterion(Evaluator.java:226)
    at com.isomorphic.criteria.Evaluator.parseAdvancedCriteria(Evaluator.java:201)
    at com.isomorphic.datasource.DataSource.parseAdvancedCriteria(DataSource.java:7294)
    at com.isomorphic.criteria.AdvancedCriteria.fromCollections(AdvancedCriteria.java:519)

DSRequest [equals]: OK

...
    data:{
        operator:"and",
        criteria:[
            {
                fieldName:"retryMaximum",
                operator:"equals",
                value:0
            }
        ]
    },
...

DSRequest [between (inclusive)]: NOT OK

...
    data:{
        operator:"and",
        criteria:[
            {
                operator:"iBetweenInclusive",
                fieldName:"retryMaximum",
                start:"0",
                end:10
            }
        ]
    }
...

Thanks

[Isomorphic]

Can you elaborate on how specifically you are "creating filters"? Is this via the FilterBuilder?

Note that if you want to specify the defaultValue as specifically being integer 0, you can do this by making defaultValue into a sub-element and using xsi:type="int" on it. This problem could be fixed at many points by having various layers tolerate an incorrectly typed defaultValue, but correcting it at the field definition level as suggested is the clearest fix.

[stonebranch2]

Hi Isomorphic,

Thank you for the feedback. We did already come up with a workaround, which appears to be working. We will keep your suggestion in our back pocket in case the need arises in the future.

To answer your question, yes, we are building a filter via the FilterBuilder.

We also noticed that the between (inclusive) entry fields can be left blank, and the resulting filter gives us an exception.

java.lang.NullPointerException
    at com.isomorphic.criteria.LogicalOperator.convertToMap(LogicalOperator.java:70)
    at com.isomorphic.criteria.AdvancedCriteria.getCriteriaAsMap(AdvancedCriteria.java:341)

We did some customization by overriding FilterBuilder.getValueFieldProperties(FieldType, String, OperatorId, ValueItemType, String) to work around this.

Any thoughts here?

Thanks

[Isomorphic]

We've fixed the framework so that a defaultValue on a field is now converted at the client during DS init, to it's native type - related server-side changes will probably follow.

We also made some changes to better deal with between-type operators - let us know if you still see any issues.

[stonebranch2]

Thank you

[Isomorphic]

Note that, with the latest changes, partial between criteria, that lack a start or end value, will no longer appear in the result of FilterBuilder.getCriteria() - this seems the most sensible option, but let us know of this is insufficient or causes any unexpected behaviors.