DataTools.findAll behaviour with different types

[claudiobosticco]

I frequently use the DataTools.findAll(java.util.List rows, java.lang.Object propertyName, java.lang.Object value) method.
When the property in a Map has a different type from the passed value, which is the expected result?

ie:
List<Map> testList = DataTools.buildList(DataTools.buildMap("number", new BigDecimal("1234")));
List match1 = DataTools.findAll(testList, "number", new Long("1234"));
List match2 = DataTools.findAll(testList, "number", "1234");
....

I'm asking because I see different behavior for different SmartClient builds, and I'd like to know before doing more test cases.

[Isomorphic]

Essentially all such values convert down to their JavaScript equivalents before comparison. In this case they are all JavaScript Number, and would be expected to match any "1234" value from an "int" or "float" field.

[claudiobosticco]

I've just made a test with:
SmartClient Version: SNAPSHOT_v9.1d_2014-01-21/PowerEdition Deployment (built 2014-01-21)
and
SmartClient Version: v9.0p_2014-01-19/PowerEdition Deployment (built 2014-01-19)

Oracle jdk1.7.0_45 on Mac OSX

I've invoked a DMI method with this fetch

JPC_CONTRATTI_BASE.fetchData({CONTRATTO_NUM:7000}, null, {operationId:"testDataToolsFindAll"})

this is the DMI code

    public DSResponse testDataToolsFindAll(DSRequest dsRequest, RPCManager rpcManager) throws Exception {
        Long contrattoNumLong = (Long) dsRequest.getCriteriaValue("CONTRATTO_NUM");
        DSRequest contrattiFetch = new DSRequest("JPC_CONTRATTI", DataSource.OP_FETCH, rpcManager);
        contrattiFetch.setCriteria("CONTRATTO_NUM", 7000);
        DSResponse dsResponse = contrattiFetch.execute();
        List<Map> dataList = dsResponse.getDataList();
        for (Map record : dataList) {
            Object contrattoNum = record.get("CONTRATTO_NUM");
            System.out.println("type of value " + contrattoNum + " in record is: " + contrattoNum.getClass().toString());
            List list = DataTools.findAll(dataList, "CONTRATTO_NUM", contrattoNumLong);
            System.out.println("list size, match with Long: " + list.size());
            list = DataTools.findAll(dataList, "CONTRATTO_NUM", "7000");
            System.out.println("list size, match with String: " + list.size());
            list = DataTools.findAll(dataList, "CONTRATTO_NUM", new BigDecimal("7000"));
            System.out.println("list size, match with BigDecimal: " + list.size());
        }
        return new DSResponse();
    }

CONTRATTO_NUM is declared as

<field sqlType="decimal" sqlLength="0" name="CONTRATTO_NUM" type="integer"/>

It always prints:

type of value 7000 in record is: class java.math.BigDecimal
list size, match with Long: 0
list size, match with String: 0
list size, match with BigDecimal: 1

so it seems to match only if also the types match!

[Isomorphic]

While we agree it's a bit counter-intuitive, this is what Java's equals() does. Try these expressions:

new Long(7000).equals(new BigDecimal(7000)); // false
new Integer(7000).equals(new BigDecimal(7000)); // false 
new BigDecimal(7000).equals(new BigDecimal(7000)); // true

Have you tried using the server-side AdvancedCriteria libraries? It's intended to be more tolerant of type differences, whereas findAll() is more of a utility method.

[claudiobosticco]

Ok, thanks, so it isn't like you said in your first reply, instead it's a bit more strict, as it is in java.

Actually I was conviced that in the past I found it to behave like a '==' in javascript.

About AdvancedCriteria: are you referring to filter the records in the fetch/SQL select?
If yes, normally I use it, but sometimes I use DataTools.findAll for other elaborations.
Or are you referring to something else I could try?

[Isomorphic]

We weren't sure whether you were referring to the client-side or server-side findAll() API. The client-side one uses JavaScript semantics so it wouldn't have an issue matching across different numeric types.

We were referring to the server-side AdvancedCriteria API - that's the literal class name, it's right there in JavaDoc.