Optional logging for streaming queries

[2x2xplz]

Requesting log settings that would notify of every execution of an ObjectBox query, especially by watched queries.

I've been experimenting with numerous reactive/streaming queries in ObjectBox, consumed by Riverpod providers. A number of these are dependent on each other, i.e. one provider's streamed queries are triggered by a change in the results of another streamed query. Because there's so much happening under the hood, I'd like to ensure that OB is only executing queries when necessary.

Describe the solution you'd like

During dev builds, I'd like to specify a log level that would trigger on every executed query. Thanks.

Describe alternatives you've considered

Logging within the Riverpod providers but they only record when a new provider (which includes a new OB streamed query) is created, but not upon each execution of a query.

Additional context

My concern is that some streamed queries may be executing far more often than necessary, for example every time a certain object is put, rather than just being triggered when the put changes a specific property.

[greenrobot-team]

for example every time a certain object is put, rather than just being triggered when the put changes a specific property.

Maybe to clear that up: as documented an event is sent when any of the boxes that are part of the query updates. There are no object-specific or property-specific events.

I don't know how your implementation looks like, but as for logging, maybe add log statements to the map or listen callbacks?

[2x2xplz]

Thanks for the quick reply. So if I understand correctly, any userBox query being watched will re-trigger upon any other userBox.put(...), regardless if if the new put has any effect on the watched query.

That's good to know. And my initial comment isn't exactly accurate, ObjectBox queries are fast so no big deal if they run frequently, the issue is if a streamed query is tied directly to the UI widget and every run triggers a new widget build. I think this is where Riverpod becomes useful, its StreamProvider will only emit a new value (triggering UI rebuild) when the result of the streamed query changes.

Cool, thanks for the explanation.