Hi @ttulka, thanks, I agree this is a useful feature.

One thing however which will cause ambiguity is the order_by field in Protobuf, which is of type string. For example, in this PR one of the fields that can be sorted on is gatewayId. When people are using the gRPC API, users would have no clue what to use (e.g. gatewayId vs gateway_id vs GatewayId vs GatewayID vs GATEWAY_ID). How gRPC / Protobuf exposes the fieldnames is language specific (gateway_id for Rust, GatewayId for Go, gatewayId for JS).

Therefore I think this should be turned into an enum. That would make it very explicit and would self-document what the available options are. As well it avoids run-time errors because of typos, because an incorrect enum value can be catched at compile time.

That would probably also mean that an order_by_desc field needs to be added (type bool) to invert the ordering.

Would you mind updating your PR with these changes?

Hi @brocaar thanks for your comments!
The proposed changes were implemented by @schmifran - could you take a second look to see if it is okay now?

The tests are failing because the code is not formatted using rustfmt. Could you check this?

@brocaar Thanks a lot for your feedback :)
I implemented all of the requested changes and also improved the formatting 👍 .

Hi @ttulka and @schmifran , this morning re-reviewed your changed + I have made some updates to simplify some things (in my opinion) and align it with the existing code (e.g. implementing the FromProto trait for the Proto conversion). This looks good to be merged. Thank you for all your work on this 👏

One question, should we only add sorting for gateways and devices, or would you like to extend this PR to also include sorting for the other tables, now that we have the structure in place for this?

Hi @brocaar Many thanks!
I find sorting important only in those two tables because the number of gws and sensors can grow rapidly (in our platform, we have hundreds of sensors, and similarly for gws) while other stuff like applications and device types usually stays in small numbers (all up to 10 in our case).

Thus, I don't see much additional value in sorting other entities for now.

Thanks again

Thanks @ttulka and @schmifran, I have merged your work 👍