Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to disable live queries #1052

Open
wmeler opened this issue Mar 14, 2023 · 6 comments
Open

Add option to disable live queries #1052

wmeler opened this issue Mar 14, 2023 · 6 comments

Comments

@wmeler
Copy link
Contributor

wmeler commented Mar 14, 2023

Sometimes druid response is slow and it would be better to disable live queries that refresh result view while building the final filters/split/measure/view set to prevent overloading druid with unneccessary queries.

I propose to:

  • change auto update "Off" mode behavoiur to not refresh result view
  • add auto update "Live query" mode that would reflect current "Off" mode
  • pull "Update now" button from auto update menu and place it over the display menu

image

I'd appreciate feedback and discussion.

@adrianmroz-allegro
Copy link
Contributor

adrianmroz-allegro commented Mar 14, 2023

  • add auto update "Live query" mode that would reflect current "Off" mode

Don't want to expose myself, but - how "Off" works right now? I thought it disables auto refresh completely?

Oh, I get it now! That's a big change from UX perspective. But I like how you made it backwards compatible.

Probably, in new mode we would grey out visualisation/pinboard after changes and enable "update now" (or just play icon) button.

That also affects url - should we change url when someone changes filters/splits but doesn't update visualisation? That sounds like a lot of ifs in weird places ...

@wmeler
Copy link
Contributor Author

wmeler commented Mar 14, 2023

Oh, I get it now! That's a big change from UX perspective. But I like how you made it backwards compatible.

The fact is that only few users notice update now button in refresh menu and click F5 or CTRL-R which cost more load on servers.

Probably, in new mode we would grey out visualisation/pinboard after changes and enable "update now" (or just play icon) button.

My colleagues say that pinboard and filters should keep refresh on every filter change because it is crucial in qube query construction. We could gray out results instead.

That also affects url - should we change url when someone changes filters/splits but doesn't update visualisation? That sounds like a lot of ifs in weird places ...

I think that url should change and reflect filter/split/measure/display state - if you refresh page it should load results.

@adrianmroz-allegro
Copy link
Contributor

I'm getting more and more convinced. Few notes.

  1. I think this setting is separate from Auto update menu. This is something different.
  2. We need config option for default mode. So admin can pick one for users.
  • Do you think we should keep user mode in local storage? Do you expect users to change this setting for themselves? Would they expect this change to persist? I'd like to avoid local storage if we really don't have to add it.
  1. Only Visualisation panel can become stale. Filter menus and pinboard refreshes just like today.
  2. Because it affects only visualisation panel, we can put UI there. After changes it become stale so we grey it out and show overlay with information an "Run" button.

@wmeler
Copy link
Contributor Author

wmeler commented Mar 21, 2023

  1. I think this setting is separate from Auto update menu. This is something different.

I won't argue, but it's related so it could be in this place.

  1. We need config option for default mode. So admin can pick one for users.
  • Do you think we should keep user mode in local storage? Do you expect users to change this setting for themselves? Would they expect this change to persist? I'd like to avoid local storage if we really don't have to add it.

Personally I would not store live query mode in local storage - I'd like to have different behaviour on different browser tabs. I'd like to force users to disable live queries on very big, heavy datacubes - so I'd prefer to have this setting in configuration on datacube level.

  1. Only Visualisation panel can become stale. Filter menus and pinboard refreshes just like today.
  2. Because it affects only visualisation panel, we can put UI there. After changes it become stale so we grey it out and show overlay with information an "Run" button.

That is great idea, but I still recommend pulling "update now" button from auto update menu.

@adrianmroz-allegro
Copy link
Contributor

adrianmroz-allegro commented Mar 24, 2023

so I'd prefer to have this setting in configuration on datacube level.

Oh, I didn't think about it. Makes sense. Probably every admin of turnilo already rolled out some config generator script so repetition there wouldn't be a problem but granularity is definitely a win.

That is great idea, but I still recommend pulling "update now" button from auto update menu.

Yeah, button for "Evaluating" changed filters will be in the middle.

"Update now" button require some rethinking. We'd like that users will embrace browser - if you need to refresh stale tab, just use browser refresh button. That will refresh everything, not only data but data cube max time which can impact time filter calendar view and who knows what else.

Out of curiosity, do you use auto refresh on any of your cubes?

@wmeler
Copy link
Contributor Author

wmeler commented Apr 3, 2023

"Update now" button require some rethinking. We'd like that users will embrace browser - if you need to refresh stale tab, just use browser refresh button. That will refresh everything, not only data but data cube max time which can impact time filter calendar view and who knows what else.

Time filter should update itself on every form display (#527)

Out of curiosity, do you use auto refresh on any of your cubes?

It's very rare. I can't remember if I used it last year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants