STA test 3 issues

[bertt]

When running STA test 3 I see 2 failing tests:

• checkQueriesPriorityOrdering

• readEntitiesWithFilterQO

Can we fix these tests?

[bertt]

Test readEntitiesWithFilterQO is discussed here: https://github.com/opengeospatial/ets-sta10/issues/37

[bertt]

Description test checkQueriesPriorityOrdering:

Request: http://localhost:8080/v1.0/Observations?$count=true&$top=1&$skip=2&$orderby=phenomenonTime%20asc&$filter=result%20gt%20'3'

Response: { "@iot.count": 9, "@iot.nextLink": "http://localhost:8080/v1.0/Observations?$filter=result gt '3'&$count=true&$orderby=phenomenonTime asc&$top=1&$skip=3", "value": [ { "@iot.id": 30, "@iot.selfLink": "http://localhost:8080/v1.0/Observations(30)", "phenomenonTime": "2015-03-06T00:00:00.000Z", "result": 6, "Datastream@iot.navigationLink": "http://localhost:8080/v1.0/Observations(30)/Datastream", "FeatureOfInterest@iot.navigationLink": "http://localhost:8080/v1.0/Observations(30)/FeatureOfInterest", "resultTime": null } ] }

Test result: The query order of execution is not correct. The expected count is 6, but the service returned 9 expected [6] but found [9] Expected :6 Actual :9

[tebben]

12 observations are posted with the following result values: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Query asks for observations where the result is > 3 = 4, 5, 6, 7, 8, 9, 10, 11, 12 = 9 returned observations. The test is not expecting observations with result 10, 11, 12 to return because of bad comparison on strings

[bertt]

is there an issue on the ets-sta site about this? Or is it the same as opengeospatial/ets-sta10#37

[bertt]

so for my understanding the issue with test 'checkQueriesPriorityOrdering' is as follows:

• database has 12 obervations with values 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
• query asks for observations > '3'
• expected result according to test: 6 observations (with values 4, 5, 6, 7, 8, 9)
• actual result: 9 observations (with values 4, 5, 6, 7, 8, 9, 10, 11, 12)

[tebben]

yes

[bertt]

analysis:

. in the GOST code the query string ('3') is converted to int (3) and then the query is performed, resulting in 9 observations (method int compare)

possible fix: in case of type mismatch (like string in the query, integer in the database) do not convert the query string from '3' to 3, but convert the observation results to string, resulting in 6 observations (method string compare).

Is this possible to do? What are the consequences?

[tebben]

It is possible but result values are inserted as integers, I'm not going to change the code to get faulty tests working. Consequences are that users do not get back the desired things, locations, datastreams, observations, etc

[bertt]

Proposal:

• Check if there is type mismatch between type of request and type in database (in the testcase type string in the query and type integer in the database)
• if typemismatch == true: Execute query (sql where part) with request as-is (no conversion) and observations.result converted to the requested type (int to string conversion in the testcase)
• if typemismatch == false: Just do the query as normal (no conversions)
• In the response (sql select part) we always send the observation.results back in the same type as inserted (integer in the testcase) - so no type conversion needed here

[bertt]

Count query: SELECT COUNT(*) FROM v1.observation WHERE observation.data -> 'result' > '3' Actual result: 9 Expected result: 6

[bertt]

Solution: change query: replace '->' with '->>' SELECT count(*) FROM v1.observation WHERE observation.data ->> 'result' > '3' Actual result: 6

[tebben]

Added a workaround for now. When filtering on observation.result with a string as input the observation.result will be fetched as string and compared