timestored / pulseui

Real-time interactive database applications
https://www.timestored.com/pulse/
Other
54 stars 6 forks source link

Allow saving filters? #196

Closed ryanhamilton closed 8 months ago

ryanhamilton commented 8 months ago

user-ag (2) "pre-saved filters / views"

DO they want to save them presearched? Inefficient on database.

ryanhamilton commented 8 months ago

User Use-cases:

  1. User wants table filter to save and to be sharable. (no query affect now but could be propagated if wanted)
  2. User wants to save/share pivot settings. (pivot affects query)
  3. User wants to save/share time-series zoom settings (zoom could in future affect query)
  4. User wants to use table filter, zoom range, pivot settings in different query?

Experiment

Using variables to store filter states is "working" but highlights a few issues:

  1. Variable name overlap, should cause tables with column A, to both have a filter when one is set.
  2. SQL queries relying on variable don't yet work. Removal of empty isn't sent properly.
  3. If we send to java, we may need to debounce.

Options:

  1. Only save filters when Interaction key is set. Problem = Requires user to know to turn on.
  2. Allow global filter overlap and suggest users set Interaction Key to differentiate. Problem = Annoying? as some column names common. e.g. date/price.
  3. Generate default InteractionKey that is unique per panel unless user sets override. Problem = Breaks existing apps that relied on overlap. Use generated key only for filter/pivot?
  4. Save to .pvt.tbl1 state variables that are generated unique and don't get propagated to anywhere. Problem: I can see them being useful in queries.
  5. Set both global and private variable versions. Only use private.

Before choosing, need to know if "local" variables can be propogated safely? I'm updating the view when the local variable is changed, NOT when it is received back from java. How should that interact with {{title}} request to set title from variables used on java end? Making these variables locally update/accessible without java creates two separate groups.

ryanhamilton commented 8 months ago

3 would be preferred - use default interaction key for new fields. If we can make all components listen to new args. To user filters just save for one table But they can use advanced java/debug if they want.

Else make them private and don't propagate to java/debug viewer. To user it just saves filter for one table without interaction. On reload() a forced overlap of setting interaction keys would show up.

ryanhamilton commented 8 months ago

Example video of pivots and filters being saved: http://timestored.com/pulse/help/table-pivot#pivfilter Released in 2.23