Hello @JO_9930585! Sorry, I'm late to the party, just wanted to hypothesize about this unusual issue...
ThingWorx uses Mozilla Rhino engine to execute your server-side JavaScript. Rhino allows you to put any Java number like byte, char, int, long or double to the script's context. Although Rhino wraps those numbers into a single JavaScript Number type, behind the scenes it actually preserves the original Java object. ThingWorx uses the "full set" of Java types on the platform level, e.g. for storing data in Data Tables, Infotables and Properties. So, inside ThingWorx platform and inside Rhino script context you have "real" Java types like int or long, but to the JavaScript code they all appear as a single generic number type, that's why your "typeof uid" always returns "number", even though in reality it is something like "number wrapper over int". This abstraction works in 99% of cases just fine, but sometimes it breaks.
For example, I was able to reproduce your problem by creating a DataTable with the uid column defined as STRING (not a NUMBER!), and query it like you do:
let result = Things["Tt"].QueryDataTableEntries({
query: {
"filters": {
"type": "EQ",
"fieldName": "uid",
"value": me.uid
}
}
});
// Also log typeof me.uid
I simplified your Infotable case and just used a Property instead. The result of this query depends on the type of me.uid -- if it's an INTEGER or LONG, the query works correctly, returning one row. But if I set it to NUMBER, the query returns zero results! The typeof me.uid always says "number", and the value is 2, but I would bet that internally Rhino uses Java Integer, Long and Double objects, respectively. By the way, I couldn't reproduce this issue with any numeric type for uid in the DataTable, only with a STRING or GUID.
So it looks like you encountered a rare corner case caused by the particular way Rhino "number" abstraction is leaking, and ThingWorx is not handling it correctly.
The best way to prevent it from happening is to ensure that the data types throughout the entire data flow are exactly the same and require as few implicit conversions as possible. If you can't ensure that, then to convert between different "numbers" you can "pass" them through Infotables, service return parameters, cast them to string and back to number, etc. -- all solutions have different level of ugliness. But probably you shouldn't even care about it, as it is exceedingly rare.
@Rocko @Velkumar You guys might find this interesting and even report this to R&D. I tested it on 9.3.1, don't have a more recent version at the moment.
P.S. This issue is not related to the fact that NUMBER is Double which can't represent integers exactly, as we are testing it with uid = 2, and Double can represent powers of 2 without errors.
/ Constantine
