Changing Pulldown selection causes upstream search to run again

[martin_mueller]

I'm building a view that roughly looks like this:

TimeRangePicker
  Search using inputlookup
    Pulldown populated by Search above
      Search building larger result set
        Pulldown using static config
          Pulldown using static config
            PostProcess applying selections from previous two Pulldowns as filter for larger result set
              Pager
                Table
                  ...more stuff...

Ideally, I'd want the Search 2 result set to be filtered whenever the Pulldown 2 or 3 is changed - without re-running Search 2. I'd expect this to work because Search 2 is upstream from Pulldown 2 and 3.

However, when I change the selection on Pulldown 2 or 3 the upstream Search 2 is run again. Any ideas?

Edit: condensed view:

<view template="dashboard.html">
  <module name="SideviewUtils" layoutPanel="appHeader" />

  <module name="Search" layoutPanel="panel_row1_col1" autoRun="True">
    <param name="earliest">-d</param>
    <param name="latest">now</param>
    <param name="search">index=_internal | stats count by sourcetype</param>

    <module name="Pulldown">
      <param name="staticOptions">
        <list>
          <param name="value">splunkd</param>
          <param name="label">splunkd</param>
        </list>
        <list>
          <param name="value">*</param>
          <param name="label">*</param>
        </list>
      </param>
      <param name="name">sourcetype</param>
      <param name="template">$name$=$value$</param>

      <module name="PostProcess">
        <param name="search">search $sourcetype$</param>
        <module name="Table" />
      </module>
    </module>
  </module>
</view>

[sideview · Accepted solution]

Note that the Pulldown here isn't actually configured as a dynamic Pulldown. It has staticOptions declared, and it's name "sourcetype" is the same field that the upstream search is grouping by, but nonetheless it has no valueField or labelField, so it wont render any dynamic options from that search.

This means that when the view determines where the search should be dispatched, the Pulldown is not considered as a "dispatching module", as per the explanation on the Sideview Utils docs page "introduction to the advanced XML".

Since Pulldown isn't a dispatching module, that means the deepest dispatching module is the PostProcess module, so the point at which the search is dispatched will always be just upstream of the PostProcess, and just downstream of your Pulldown.

Solutions:

1) In this case I think you meant for the Pulldown to actually render the values of sourcetype, so you could add <param name="valueField">sourcetype</param> to the Pulldown, that would turn the Pulldown into a "dispatching module", which would make the framework dispatch the search just upstream of it.

2) In some cases you just want to force the framework to dispatch your search a little bit upstream of where it would normally. To do this you can put in some dispatching module...

a) Often there is already a need for a JobProgressIndicator module somewhere, and you usually have a lot of freedom as to where exactly it goes. So often you can shift this thing around and make it force your dispatch for you.

b) If there isn't some convenient dispatching module to throw into the right spot, you have a last resort of:

<module name="CustomBehavior">
  <param name="requiresDispatch">True</param>
</module>

CustomBehavior is an advanced module that you normally give a "customBehavior" param, the exact nature of which you then define in application.js (there are docs, a link to which is hidden on the "Other > Tools" page. However it also has this requiresDispatch param and it can come in handy just for that, albeit in unusual situations)

And in conclusion, the two ideas discussed at length in that "Introduction to the Advanced XML" are extremely important to really understanding the advanced XML. The first is just the concept of upstream/downstream, and the importance of that. But the second is "why, when where and how are searches dispatched/". Here you might think that the search is an upstream search, because the Search module is upstream, but the "search" itself is being dispatched downstream from the Pulldown!

[martin_mueller]

I think that makes sense 🙂

The pulldown is static in this condensed view because it's static in the more complex example - it'll perform an SQL-like "between" on execution durations.

I'll give the JobProgressIndicator a chance to force dispatching, that indeed should be flexible in its position.

Edit: It works! +beer

[martin_mueller]

I've condensed the view to its minimal form with queries that everyone can run, and still see the search run when changing the pulldown selection, despite the search being upstream from the pulldown.