Solr
  1. Solr
  2. SOLR-1067

QueryParsing.parseFunction uses Singleton Core (SolrCore.getSolrCore())

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      QueryParsing.parseFunction is a static utility method that depends on the SolrCore.getSolrCore singleton – but it is not yet deprecated and is used in some rather important places in the code base (the result is that the last core initialized

      it was noted a while back, with some comments about how to tackle the problem, but it looks like we never opened an issue to deal with it...

      http://www.nabble.com/QueryParsing-using-SolrCore.getSolrCore()-td19806087.html

      ...we should deal with this in some way prior to the 1.4 release (if nothing else, we need to document it as a caveat).

      1. SOLR-1067.patch
        7 kB
        Yonik Seeley

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          no longer a problem in 4.0 due to both of these (deprecated) methods having been removed.

          Show
          Hoss Man added a comment - no longer a problem in 4.0 due to both of these (deprecated) methods having been removed.
          Hide
          Hoss Man added a comment -

          Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19.

          Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited

          Show
          Hoss Man added a comment - Bulk changing fixVersion 3.6 to 4.0 for any open issues that are unassigned and have not been updated since March 19. Email spam suppressed for this bulk edit; search for hoss20120323nofix36 to identify all issues edited
          Hide
          Robert Muir added a comment -

          3.4 -> 3.5

          Show
          Robert Muir added a comment - 3.4 -> 3.5
          Hide
          Robert Muir added a comment -

          Bulk move 3.2 -> 3.3

          Show
          Robert Muir added a comment - Bulk move 3.2 -> 3.3
          Hide
          Hoss Man added a comment -

          Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

          http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

          Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

          A unique token for finding these 240 issues in the future: hossversioncleanup20100527

          Show
          Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
          Hide
          Yonik Seeley added a comment -

          I think we've done everything reasonable for 1.4, moving the rest to 1.5

          Show
          Yonik Seeley added a comment - I think we've done everything reasonable for 1.4, moving the rest to 1.5
          Hide
          Yonik Seeley added a comment -

          Here's a patch that incrementally improves the situation.
          I think the only place a QParser isn't used now is deleteByQuery.

          Show
          Yonik Seeley added a comment - Here's a patch that incrementally improves the situation. I think the only place a QParser isn't used now is deleteByQuery.
          Hide
          Hoss Man added a comment -

          to followup on a comment i made in that email thread...

          The sanest thing to do would probably be to make parseFunction construct a
          local instance of FunctionQParser (with a null SolrQueryRequest) instead
          of using QParser.getParser(...). that should be fairly close to the way
          it worked in older versions

          (hmmm... except FunctionQParser does something similar to get a
          ValueSourceParser ... a new constructor for FunctionQParser that
          explicitly tells it to use ValueSourceParser.standardValueSourceParsers
          might be in order).

          I think it goes without saying that QueryParsing.parseFunction should be
          deprecated as well ... fortunately it's only used in a few places in the
          core code ... unfortunately those places also don't currently have access
          to a SolrQueryRequest at the moment:
          1) SolrPluginUtils.parseFuncs – should probably be deprecated, callers
          of it should start using the QParser APIs.
          2) SolrQueryParser.getFieldQuery – it's only used if the
          SolrQueryParser was constructed with an IndexSchema and not with a QParser
          (in which case it can ask the QParser for a subParser) .. the IndexSchema
          constructor should probably be deprecated as well (but i haven't dug in to
          see how far down the rabit hole that change would go)

          If we gave FunctionQParser a constructor that took in an IndexSchema instead of a SolrQueryRequest, then that new constructor could be used by both QueryParsing.parseFunction and SolrQueryParser.getFieldQuery and – we'd still need to use the ValueSourceParser.standardValueSourceParsers as well, but that would be better then picking the ones declared arbitrarily in the last core.

          Show
          Hoss Man added a comment - to followup on a comment i made in that email thread... The sanest thing to do would probably be to make parseFunction construct a local instance of FunctionQParser (with a null SolrQueryRequest) instead of using QParser.getParser(...). that should be fairly close to the way it worked in older versions (hmmm... except FunctionQParser does something similar to get a ValueSourceParser ... a new constructor for FunctionQParser that explicitly tells it to use ValueSourceParser.standardValueSourceParsers might be in order). I think it goes without saying that QueryParsing.parseFunction should be deprecated as well ... fortunately it's only used in a few places in the core code ... unfortunately those places also don't currently have access to a SolrQueryRequest at the moment: 1) SolrPluginUtils.parseFuncs – should probably be deprecated, callers of it should start using the QParser APIs. 2) SolrQueryParser.getFieldQuery – it's only used if the SolrQueryParser was constructed with an IndexSchema and not with a QParser (in which case it can ask the QParser for a subParser) .. the IndexSchema constructor should probably be deprecated as well (but i haven't dug in to see how far down the rabit hole that change would go) If we gave FunctionQParser a constructor that took in an IndexSchema instead of a SolrQueryRequest, then that new constructor could be used by both QueryParsing.parseFunction and SolrQueryParser.getFieldQuery and – we'd still need to use the ValueSourceParser.standardValueSourceParsers as well, but that would be better then picking the ones declared arbitrarily in the last core.

            People

            • Assignee:
              Unassigned
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development