Device search API: support for OR operator

[spulci]

Hi,

we've got an use case that needs the presence of an OR operator for device searching (actually limited to EQ operator only): for example we'd like to search for the same value string for a specified set of fields. E.g.

{ "fields":  "["/deviceName","/manufacturerName"]", "op": "OR", value: "x"}

where fields actually does not exist and it should support an array of strings.

The API lacks of this kind of logic and we can try to implement in our backend with multiple API calls to support pagination (one call per field to be searched): this scenario shift some complexity and performance issues on our side (especially if we have to make UNIONs of multiple api call results to manage pagination of these union).

Can we evaluate to add this operator to the HONO seatch device GET API? Are there any valid reasons why this kind of operator has not been implemented yet, leaving EQ as the only one available?

[sophokles73]

The filterJson query parameter supports sepcifying multiple predicates already:

If this parameter is specified multiple times, objects in the result set must match all predicates.

The op field in the predicate can not be used to alter the logic for combining multiple predicates but is only relevant for the predicate itself and determines how the given value is being compared to the field.

In order to support the desired behavior, you would therefore need to come up with a mechanism to specify expressions based on boolean operators and predicates other than just using AND implicitly.

While this seems possible, I believe it would require quite some changes to the Mongo DB and JDBC based implementations. The (example) device registry implementations that come with Hono are designed to meet the requirements of the protocol adapters, which are mainly to retrieve information relevant for authentication based on a tenant and authentication identifier.

The functionality that you are describing is required for doing device management beyond simple device provisioning activities. Adding more and more of this kind of functionality to the registry makes the code harder and harder to maintain and understand while at the same there will always be additional requirements coming from somebody's specific use case.

I therefore advise to either

1. create your own (additional) management API on top of the existing Mongo DB, or
2. implement your own device registry using whatever technology you want and implement those operations of Hono's management API that are required by the protocol adapters.

You can then implement all sorts of specific search and filter functionality etc based on your use case at hand.