Query term "q" is not working properly in federated entities when more than one condition

[ravaga]

I'm testing the query parameter q in an environment with two Orion-LD instances with crossed Context Source Resgistrations of type IE. I can retrieve all the entities of type IE from both brokers by calling one of both, however, when I use the q parameter with more than one condition the results are not filtered properly. It seems to work properly with just a single condition (e.g. q=cpuCores>2).

I tried some combinations, for instance:

• (ramCapacity>1000&ramCapacity<4000)
• ramCapacity>1000&ramCapacity<4000
• ramCapacity>1000;ramCapacity<4000
• ramCapacity>1000;ramCapacity<4000&cpuCores>1

but it sometimes works as expected and sometimes not, so I can't find a failure pattern. Even the same filter value returns a different value if I make the request to the other broker.

[kzangeli]

So, I ran some tests and found a bug in the broker.

First of all, q=ramCapacity>1000&ramCapacity<4000 can never work, not as is. The q must be URL-encoded, cause, otherwise, ramCapacity (the second one) is a standalone URL parameter, and not part of the 'q', and that will result in a 400 Bad Request (URL Parameter 'ramCapacity` not supported). BUT, even when URL-encoded, when the broker sends the forwarded request it DOES NOT urlencode the '&', which is a bug. I will fix that error, of course.

Now, using ';' as AND operator I found no problem, so if combination 3 (q=ramCapacity>1000;ramCapacity<4000) really doesn't work, we need to look into that. So, please test that again, cause, I did and I had no problem with it.

[kzangeli]

So, seems like it wasn't enough. krakenD doesn't like ';' in the URL. Hopefully an urlencoded '&' will do the trick.

[ravaga]

Solved, it works now with urlencoded '&' in forwarded requests.