Solr
  1. Solr
  2. SOLR-1373

Add filter query in solr/admin/form.jsp

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: web gui
    • Labels:
      None

      Description

      The full interface needs a filter query text field.

      1. SOLR-1373.patch
        0.4 kB
        Jason Rutherglen

        Activity

        Hide
        Grant Ingersoll added a comment -

        Bulk close for Solr 1.4

        Show
        Grant Ingersoll added a comment - Bulk close for Solr 1.4
        Hide
        Lance Norskog added a comment -

        Maybe there should be two 'Full Interface' pages?

        The current Full Interface page has the "handing a bomb to a baby" problem for very large indexes. For example, some things like sorting or faceting can kill a large index. Maybe the super-full page would include a default of 5 seconds for the solr timeout?

        Show
        Lance Norskog added a comment - Maybe there should be two 'Full Interface' pages? The current Full Interface page has the "handing a bomb to a baby" problem for very large indexes. For example, some things like sorting or faceting can kill a large index. Maybe the super-full page would include a default of 5 seconds for the solr timeout?
        Hide
        Hoss Man added a comment -

        Anything that's commonly used should be in Solr's equivalent of advanced search

        Agreed ... but there is a risk that some "common" options aren't ubiqutious, so if we add them to the form people could get confused if a param doesn't work because the request handler they are using doesn't support it

        in the case of fq, i think the pros outway the cons ... that's why i committed your patch.

        I'm curious why we're not interested in making a more advanced UI?

        i don't remember anyone saying that ... i just don't think hardcoding a bunch of params into form.jsp is the way to go. i'd love to see a good UI that could inspect the solr conifuration and display the appropriate options in a GUI – ala the wiki page i mentioned (but aparently didn't link to) ...

        http://wiki.apache.org/solr/MakeSolrMoreSelfService

        Show
        Hoss Man added a comment - Anything that's commonly used should be in Solr's equivalent of advanced search Agreed ... but there is a risk that some "common" options aren't ubiqutious, so if we add them to the form people could get confused if a param doesn't work because the request handler they are using doesn't support it in the case of fq, i think the pros outway the cons ... that's why i committed your patch. I'm curious why we're not interested in making a more advanced UI? i don't remember anyone saying that ... i just don't think hardcoding a bunch of params into form.jsp is the way to go. i'd love to see a good UI that could inspect the solr conifuration and display the appropriate options in a GUI – ala the wiki page i mentioned (but aparently didn't link to) ... http://wiki.apache.org/solr/MakeSolrMoreSelfService
        Hide
        Jason Rutherglen added a comment -

        Anything that's commonly used should be in Solr's equivalent of
        advanced search. Users ask me what is a filter query, they don't
        know exists, and end up writing clauses that should be filters
        in the query section. Putting fq in the form.jsp will hopefully
        help.

        I'm curious why we're not interested in making a more advanced
        UI?

        Show
        Jason Rutherglen added a comment - Anything that's commonly used should be in Solr's equivalent of advanced search. Users ask me what is a filter query, they don't know exists, and end up writing clauses that should be filters in the query section. Putting fq in the form.jsp will hopefully help. I'm curious why we're not interested in making a more advanced UI?
        Hide
        Erik Hatcher added a comment -

        Yeah, I kinda cringed with this one myself, but it's a basic one that seems reasonable to add... but then so could a defType selector, etc. Now we're talking Solr Explorer and the realm of front-end frameworks like Flare, Solritas, and others popping up.

        Show
        Erik Hatcher added a comment - Yeah, I kinda cringed with this one myself, but it's a basic one that seems reasonable to add... but then so could a defType selector, etc. Now we're talking Solr Explorer and the realm of front-end frameworks like Flare, Solritas, and others popping up.
        Hide
        Hoss Man added a comment -

        I'm generally opposed to a proliferation of params on the admin search form (unless we add a way for them to be configured ala MakeSolrMoreSelfService) but fq is at least as ubiquitous as highlighting at this point.

        Committed revision 806303.

        Show
        Hoss Man added a comment - I'm generally opposed to a proliferation of params on the admin search form (unless we add a way for them to be configured ala MakeSolrMoreSelfService) but fq is at least as ubiquitous as highlighting at this point. Committed revision 806303.
        Hide
        Jason Rutherglen added a comment -

        Patch

        Show
        Jason Rutherglen added a comment - Patch

          People

          • Assignee:
            Hoss Man
            Reporter:
            Jason Rutherglen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development