Identifier format in URL request

[ndevilleBE]

Dear,
While working on the optimization of sensorthings, I realize that the way to construct the URL can have a massive impact on the performance. If you look for a specific entities by its ID, there is two way to get an answer from the API:

https://sensors.naturalsciences.be/sta/v1.1/Locations?$filter=@iot.id eq 516655&$expand=HistoricalLocations($select=time)

and

https://sensors.naturalsciences.be/sta/v1.1/Locations?$filter=@iot.id eq '516655'&$expand=HistoricalLocations($select=time)

Both URLs work but the first one is instantaneous, the second one takes 1 minute.
The reason is that if you put the identifier between quote, the SQL query sent to the server will CAST all the database identifiers as varchar then make the comparison. This is very slow of course.
-> is it a bug in the API or is it a normal behaviour?

Kind regards

[hylkevds]

That is by design. If you tell FROST to compare something to a String, it'll have to convert that something to a String. Since everything can be converted to a String that's the fallback.

In theory, when comparing a number to a string constant, FROST could try to convert the String constant to a number...

[ndevilleBE]

I'm not familiar with the internal engine of FROST, but at the database level it'll throw an error if you bluntly compare a string to an integer. I don't how/if this should be implemented at the FROST level for @iot.id ?!

[hylkevds]

Yes, that's why FROST checks the data types and casts the number to a string if needed, since that cast is always possible.

The client knows if the @iot.id is a String or a Number, since they are encoded differently in JSON. So the client is responsible for not turning numbers into strings...