Solr
  1. Solr
  2. SOLR-3232

Admin UI: query form should have a menu to pick a request handler

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: web gui
    • Labels:
      None

      Description

      The query form in the admin UI could use an improvement regarding how the request handler is chosen; presently all there is is a text input for 'qt'. The first choice to make in the form above the query should really be the request handler since it actually handles the request before any other parameters do anything. It'd be great if it was a dynamically driven menu defaulting to "/select". Similar to how the DIH page finds DIH request handlers, this page could find the request handlers with a class of "SearchHandler". Their names would be added to a list, and if the name didn't start with a '/' then it would be prefixed with '/select?qt='.

      I did something similar (without the menu) to the old 3x UI in a patch to SOLR-3161 which will hopefully get committed.

      1. SOLR-3232.patch
        3 kB
        Stefan Matheis (steffkes)

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          I opened SOLR-3774 to look into the weird bug of search handler registration.

          in the meantime, this doesn't seem like something that is being actively worked on, or should hold up 4.0, so removing it from the fixVersion

          Show
          Hoss Man added a comment - I opened SOLR-3774 to look into the weird bug of search handler registration. in the meantime, this doesn't seem like something that is being actively worked on, or should hold up 4.0, so removing it from the fixVersion
          Hide
          Robert Muir added a comment -

          rmuir20120906-bulk-40-change

          Show
          Robert Muir added a comment - rmuir20120906-bulk-40-change
          Hide
          Hoss Man added a comment -

          bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

          Show
          Hoss Man added a comment - bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment
          Hide
          David Smiley added a comment -

          This issue has stalled, but it's blocking a related issue.

          I created a separate issue for the qt / path handling and how it's placed in the UI: SOLR-3317 That issue should be easy to tackle.

          This issue should be strictly about the menu, not about qt/path stuff.

          Show
          David Smiley added a comment - This issue has stalled, but it's blocking a related issue. I created a separate issue for the qt / path handling and how it's placed in the UI: SOLR-3317 That issue should be easy to tackle. This issue should be strictly about the menu, not about qt/path stuff.
          Hide
          David Smiley added a comment -

          I took a stab at coding Hoss's idea, /admin/mbeans?class=solr.SearchHandler but I'm disappointed with the results. Along with some valid entries with names equal to the request handler names (/get search /browse) it also turned up one with the name "org.apache.solr.handler.RealTimeGetHandler" and another with the name "org.apache.solr.handler.component.SearchHandler" – pretty weird. Maybe the right solution is a new /admin/handlers that gets the request handlers directly from the core.

          Show
          David Smiley added a comment - I took a stab at coding Hoss's idea, /admin/mbeans?class=solr.SearchHandler but I'm disappointed with the results. Along with some valid entries with names equal to the request handler names (/get search /browse) it also turned up one with the name "org.apache.solr.handler.RealTimeGetHandler" and another with the name "org.apache.solr.handler.component.SearchHandler" – pretty weird. Maybe the right solution is a new /admin/handlers that gets the request handlers directly from the core.
          Hide
          Erik Hatcher added a comment - - edited

          the old JSPs and the velocity engine generated pages had too much direct access to internals, making it too easy to overlook when external clients didn't have access to useful data.

          My reply to that is that with VrW you can give the client basically whatever it needs in this Ajax-world, by generating exactly what the client needs (either an HTML snippet to drop in or text suggestions as in /browse; HTML snippets can include setting a JavaScript variable looking at internals, for example). Don't get me wrong, I understand fully the desire and need for useful data being sent via the general response writer infrastructure, and not fighting progress on that, just the instant reaction to add something to the response that in this case is likely not mapping to what the internal routing logic is doing and also being a bit gratuitous to have it all in JSON when a decent way to get the data needed for this individual use case is already there. Simply being pragmatic, adding less code.

          And I'm particularly +1 on making "querying the AdminHandler return all sorts of useful introspection info about what is currently running to drive the UI screen generation". I've been a big fan of the request handler param introspectability for sure. Anyone seen how Ant tasks are built under the covers? I'm thinking like that. We introspected Ant's own Java API to generate the task reference in "Java Development with Ant", complete with parameter and nested element names, data types, and descriptions (even enumerated values).

          Show
          Erik Hatcher added a comment - - edited the old JSPs and the velocity engine generated pages had too much direct access to internals, making it too easy to overlook when external clients didn't have access to useful data. My reply to that is that with VrW you can give the client basically whatever it needs in this Ajax-world, by generating exactly what the client needs (either an HTML snippet to drop in or text suggestions as in /browse; HTML snippets can include setting a JavaScript variable looking at internals, for example). Don't get me wrong, I understand fully the desire and need for useful data being sent via the general response writer infrastructure, and not fighting progress on that, just the instant reaction to add something to the response that in this case is likely not mapping to what the internal routing logic is doing and also being a bit gratuitous to have it all in JSON when a decent way to get the data needed for this individual use case is already there. Simply being pragmatic, adding less code. And I'm particularly +1 on making "querying the AdminHandler return all sorts of useful introspection info about what is currently running to drive the UI screen generation". I've been a big fan of the request handler param introspectability for sure. Anyone seen how Ant tasks are built under the covers? I'm thinking like that. We introspected Ant's own Java API to generate the task reference in "Java Development with Ant", complete with parameter and nested element names, data types, and descriptions (even enumerated values).
          Hide
          Hoss Man added a comment -

          Anyway, I'll let it go, and just roll my eyes at all the hacks and duplication that building an entirely Ajax UI using pure JSON responses entails.

          I've said it before and i'll say it again: the single most important reason why i think the javascript based Admin UI is a great idea is becuase it forces us to make sure all of the info needed to build the admin UI is available via HTTP using request handlers and what no – ensuring that we think about how other clients can programmatically access the same information. the old JSPs and the velocity engine generated pages had too much direct access to internals, making it too easy to overlook when external clients didn't have access to useful data.

          How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false?

          I think it would be just as easy and far more generally useful add a request param to SolrInfoMBeanHandler that would let you filter the objects by what class's they are an instance of just like it can filter by "cat" and "key" right now (ie: "/admin/mbeans?class=solr.SearchHandler").

          As far as this issue in general: i think it's a good idea to add a pulldown to make it more friendly to folks and easier to use in the common case, and populating the pulldown with all the instances of SerachHandler makes a lot of sense, but we should try to use some UI element that will allows people to type in their own handler name if they want (ie: http://jsfiddle.net/6QeXU/3/ but i'm sure thers a clearner more efficient way to do it) so we don't anoy people who have their own custom RequestHandlers that don't subclass SerachHandler, or want to use things like MoreLikeThisHandler, etc...)

          (Longer term, it would be to make querying the AdminHandler return all sorts of useful introspection info about what is currently running to drive the UI screen generation, with optional config on the handler to override things maybe i don't wnat to advertise some search handler instance?) along the lines of this brainstorming doc i write a long, long time ago: http://wiki.apache.org/solr/MakeSolrMoreSelfService#Request_Handler_Param_Docs)

          Show
          Hoss Man added a comment - Anyway, I'll let it go, and just roll my eyes at all the hacks and duplication that building an entirely Ajax UI using pure JSON responses entails. I've said it before and i'll say it again: the single most important reason why i think the javascript based Admin UI is a great idea is becuase it forces us to make sure all of the info needed to build the admin UI is available via HTTP using request handlers and what no – ensuring that we think about how other clients can programmatically access the same information. the old JSPs and the velocity engine generated pages had too much direct access to internals, making it too easy to overlook when external clients didn't have access to useful data. How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false? I think it would be just as easy and far more generally useful add a request param to SolrInfoMBeanHandler that would let you filter the objects by what class's they are an instance of just like it can filter by "cat" and "key" right now (ie: "/admin/mbeans?class=solr.SearchHandler"). – As far as this issue in general: i think it's a good idea to add a pulldown to make it more friendly to folks and easier to use in the common case, and populating the pulldown with all the instances of SerachHandler makes a lot of sense, but we should try to use some UI element that will allows people to type in their own handler name if they want (ie: http://jsfiddle.net/6QeXU/3/ but i'm sure thers a clearner more efficient way to do it) so we don't anoy people who have their own custom RequestHandlers that don't subclass SerachHandler, or want to use things like MoreLikeThisHandler, etc...) (Longer term, it would be to make querying the AdminHandler return all sorts of useful introspection info about what is currently running to drive the UI screen generation, with optional config on the handler to override things maybe i don't wnat to advertise some search handler instance?) along the lines of this brainstorming doc i write a long, long time ago: http://wiki.apache.org/solr/MakeSolrMoreSelfService#Request_Handler_Param_Docs )
          Hide
          Stefan Matheis (steffkes) added a comment -

          How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false?

          +1

          Just to note it, some of the Handlers which are defined with startup="lazy" are shown as Lazy[solr.SearchHandler] in the mbean-Output, don't know if this requires a specific Handling

          Show
          Stefan Matheis (steffkes) added a comment - How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false? +1 Just to note it, some of the Handlers which are defined with startup="lazy" are shown as Lazy [solr.SearchHandler] in the mbean-Output, don't know if this requires a specific Handling
          Hide
          Mark Miller added a comment -

          How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false?

          +1 - something like that sounds reasonable. No reason you shouldn't be able to determine this from SolrInfoMBeanHandler.

          Show
          Mark Miller added a comment - How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false? +1 - something like that sounds reasonable. No reason you shouldn't be able to determine this from SolrInfoMBeanHandler.
          Hide
          Erik Hatcher added a comment -

          Erik, I admit that your /handlers Velocity template presented in SOLR-3161 was remarkably succinct and readable but it does force the use of Velocity which isn't in core, just as JSPs aren't for similar reasons.

          I'll admit to beating a dead horse here I suppose. It's a bit frustrating that something that is so easy and trivial using something already sort-of available isn't really available. But the reasons aren't really that similar.... JSPs require a JDK. VRW only requires another .jar. Anyway, I'll let it go, and just roll my eyes at all the hacks and duplication that building an entirely Ajax UI using pure JSON responses entails.

          Show
          Erik Hatcher added a comment - Erik, I admit that your /handlers Velocity template presented in SOLR-3161 was remarkably succinct and readable but it does force the use of Velocity which isn't in core, just as JSPs aren't for similar reasons. I'll admit to beating a dead horse here I suppose. It's a bit frustrating that something that is so easy and trivial using something already sort-of available isn't really available. But the reasons aren't really that similar.... JSPs require a JDK. VRW only requires another .jar. Anyway, I'll let it go, and just roll my eyes at all the hacks and duplication that building an entirely Ajax UI using pure JSON responses entails.
          Hide
          David Smiley added a comment -

          Erik, I admit that your /handlers Velocity template presented in SOLR-3161 was remarkably succinct and readable but it does force the use of Velocity which isn't in core, just as JSPs aren't for similar reasons. How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false?

          Show
          David Smiley added a comment - Erik, I admit that your /handlers Velocity template presented in SOLR-3161 was remarkably succinct and readable but it does force the use of Velocity which isn't in core, just as JSPs aren't for similar reasons. How about SolrInfoMBeanHandler.java adds a simple "searchHandler" attribute with true/false?
          Hide
          Erik Hatcher added a comment -

          Stefan - /browse and search are SearchHandler's. Even with SOLR-3161, these are legitimate request handlers to issue search requests to.

          In your page you have this:

          handlers[key]['class'] === 'org.apache.solr.handler.component.SearchHandler'
          

          That simply isn't sufficient for determining a SearchHandler though.... and this points out more about why doing this sort of stuff client-side is brittle. You really need a Java-side "instanceof" check to be sure if a request handler is subclassed from SearchHandler, not just directly but perhaps indirectly (like StandardRequestHandler).

          Again, I'll just toss this out there because I feel strongly about HTML-inside-JavaScript-strings and everything coming from Ajax calls this way - the VelocityResponseWriter allows for very simple server-side templating and internal access to these sorts of things. It'd be easy to generate a drop-down box (or JavaScript string array, whatever you'd like) using Solr's internal state and instanceof kinda checks. An example from your patch on this is:

          Also, in light of SOLR-3161, it's risky to add checks for acceptable request handlers anywhere in a secondary manner as the logic may not match. It's important to ensure that what's presented matches what is truly available, and this be done using common server-side logic.

          Show
          Erik Hatcher added a comment - Stefan - /browse and search are SearchHandler's. Even with SOLR-3161 , these are legitimate request handlers to issue search requests to. In your page you have this: handlers[key]['class'] === 'org.apache.solr.handler.component.SearchHandler' That simply isn't sufficient for determining a SearchHandler though.... and this points out more about why doing this sort of stuff client-side is brittle. You really need a Java-side "instanceof" check to be sure if a request handler is subclassed from SearchHandler, not just directly but perhaps indirectly (like StandardRequestHandler). Again, I'll just toss this out there because I feel strongly about HTML-inside-JavaScript-strings and everything coming from Ajax calls this way - the VelocityResponseWriter allows for very simple server-side templating and internal access to these sorts of things. It'd be easy to generate a drop-down box (or JavaScript string array, whatever you'd like) using Solr's internal state and instanceof kinda checks. An example from your patch on this is: Also, in light of SOLR-3161 , it's risky to add checks for acceptable request handlers anywhere in a secondary manner as the logic may not match. It's important to ensure that what's presented matches what is truly available, and this be done using common server-side logic.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Something like that David?

          Actually i'm getting "/browse" and "search" as possible Handlers, i guess this is because SOLR-3161 is pending, right?

          Show
          Stefan Matheis (steffkes) added a comment - Something like that David? Actually i'm getting "/browse" and "search" as possible Handlers, i guess this is because SOLR-3161 is pending, right?

            People

            • Assignee:
              Unassigned
              Reporter:
              David Smiley
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development