Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-7495

Unexpected docvalues type NUMERIC when grouping by a int facet

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.0, 5.1, 5.2, 5.3
    • Fix Version/s: 6.4
    • Component/s: None
    • Labels:
      None

      Description

      Hey All,
      After upgrading from solr 4.10 to 5.1 with solr could
      I'm getting a IllegalStateException when i try to facet a int field.

      IllegalStateException: unexpected docvalues type NUMERIC for field 'year' (expected=SORTED). Use UninvertingReader or index with docvalues.

      schema.xml

      <?xml version="1.0" ?>
      <schema name="schema" version="1.2">
          <fields>
              <!-- solar cloud version field -->
              <field name="_version_" type="long" indexed="true" stored="true"/>
      
              <!-- Common fields -->
              <field name="id" type="string" indexed="true" stored="true"  multiValued="false" required="true"/>
              <field name="index_type" type="string" indexed="true"  stored="true"  multiValued="false" required="true"/>
      
              <field name="year" type="int" indexed="true" stored="true"/>
              <field name="model" type="string" indexed="true" stored="true"/>
              <field name="year_make_model" type="string" indexed="true" stored="true"/>
          </fields>
      
          <!-- Field Types -->
          <types>
              <fieldType name="string" class="solr.StrField" sortMissingLast="true" />
              <fieldType name="boolean" class="solr.BoolField" sortMissingLast="true"/>
              <fieldType name="int" class="solr.TrieIntField" precisionStep="0" positionIncrementGap="0"/>
              <fieldType name="float" class="solr.TrieFloatField" precisionStep="0" positionIncrementGap="0"/>
              <fieldType name="long" class="solr.TrieLongField" precisionStep="0" positionIncrementGap="0"/>
              <fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" positionIncrementGap="0"/>
              <fieldType name="date" class="solr.TrieDateField" precisionStep="0" positionIncrementGap="0"/>
              <fieldType name="text_ngram" class="solr.TextField" positionIncrementGap="100">
                  <analyzer type="index">
                      <tokenizer class="solr.StandardTokenizerFactory"/>
                      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
                      <filter class="solr.LowerCaseFilterFactory"/>
                      <filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="15"/>
                  </analyzer>
                  <analyzer type="query">
                      <tokenizer class="solr.StandardTokenizerFactory"/>
                      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
                      <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
                      <filter class="solr.LowerCaseFilterFactory"/>
                  </analyzer>
              </fieldType>
              <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
                  <analyzer type="index">
                      <tokenizer class="solr.StandardTokenizerFactory"/>
                      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
                      <filter class="solr.LowerCaseFilterFactory"/>
                      <filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="15"/>
                  </analyzer>
                  <analyzer type="query">
                      <tokenizer class="solr.StandardTokenizerFactory"/>
                      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />
                      <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
                      <filter class="solr.LowerCaseFilterFactory"/>
                  </analyzer>
              </fieldType>
      
              <fieldType name="location_rpt" class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" distErrPct="0.025" maxDistErr="0.000009" units="degrees" />
          </types>
      
          <uniqueKey>id</uniqueKey>
      
          <defaultSearchField>name</defaultSearchField>
      
          <solrQueryParser defaultOperator="OR"/>
      </schema>
      

      query :

      http://solr.dev:8983/solr/my_collection/select?wt=json&fl=id&fq=index_type:foobar&group=true&group.field=year_make_model&group.facet=true&facet=true&facet.field=year
      

      Exception :

      ull:org.apache.solr.common.SolrException: Exception during facet.field: year
          at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
          at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
          at java.util.concurrent.FutureTask.run(FutureTask.java:262)
          at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
          at org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
          at org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
          at org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
          at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
          at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
          at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
          at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
          at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
          at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
          at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
          at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
          at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
          at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
          at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
          at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
          at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
          at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
          at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
          at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
          at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
          at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
          at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
          at org.eclipse.jetty.server.Server.handle(Server.java:368)
          at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
          at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
          at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
          at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
          at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
          at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
          at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
          at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
          at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
          at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
          at java.lang.Thread.run(Thread.java:745)
      Caused by: java.lang.IllegalStateException: unexpected docvalues type NUMERIC for field 'year' (expected=SORTED). Use UninvertingReader or index with docvalues.
          at org.apache.lucene.index.DocValues.checkField(DocValues.java:208)
          at org.apache.lucene.index.DocValues.getSorted(DocValues.java:264)
          at org.apache.lucene.search.grouping.term.TermGroupFacetCollector$SV.doSetNextReader(TermGroupFacetCollector.java:135)
          at org.apache.lucene.search.SimpleCollector.getLeafCollector(SimpleCollector.java:33)
          at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:705)
          at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:428)
          at org.apache.solr.request.SimpleFacets.getGroupedCounts(SimpleFacets.java:532)
          at org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:458)
          at org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:381)
          at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:621)
          ... 37 more
      
      org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://10.0.2.15:8983/solr/my_collection_shard2_replica1: Exception during facet.field: year
          at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:556)
          at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:233)
          at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:225)
          at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
          at org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:221)
          at org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:184)
          at java.util.concurrent.FutureTask.run(FutureTask.java:262)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
          at java.util.concurrent.FutureTask.run(FutureTask.java:262)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          at java.lang.Thread.run(Thread.java:745)
      
      1. SOLR-7495.patch
        5 kB
        Dennis Gove
      2. SOLR-7495.patch
        7 kB
        Scott Stults
      3. SOLR-7495.patch
        2 kB
        Varun Thacker

        Issue Links

          Activity

          Hide
          dizzu333 Ovidiu Mihalcea added a comment -

          I'm having the same problem, Solr 5.1, without using SolrCloud.
          The problem seemed to have been fixed if I made the field I was trying to facet on multivalued. But then the logs were all full of "Error creating FieldCache for field: brand_id"
          We wanted to upgrade to Solr 5.1, but we cannot get past this bug.

          Show
          dizzu333 Ovidiu Mihalcea added a comment - I'm having the same problem, Solr 5.1, without using SolrCloud. The problem seemed to have been fixed if I made the field I was trying to facet on multivalued. But then the logs were all full of "Error creating FieldCache for field: brand_id" We wanted to upgrade to Solr 5.1, but we cannot get past this bug.
          Hide
          simpleBread Xu Zhang added a comment - - edited

          Currently, I think Facet.field only works fine when the it is multi-valued or single-valued StrField when grouping. There isn't a GroupedFacetCollector that works on numerics.

          The reason is in TermGroupFacetCollector class, we init facetFieldTermsIndex as SortedDocValues (if single-valued). In this case, if facet.field is numeric, it will throw this exception.

          Show
          simpleBread Xu Zhang added a comment - - edited Currently, I think Facet.field only works fine when the it is multi-valued or single-valued StrField when grouping. There isn't a GroupedFacetCollector that works on numerics. The reason is in TermGroupFacetCollector class, we init facetFieldTermsIndex as SortedDocValues (if single-valued). In this case, if facet.field is numeric, it will throw this exception.
          Hide
          ncoult Nick Coult added a comment -

          We are having the same problem in Solr 5.2.

          Show
          ncoult Nick Coult added a comment - We are having the same problem in Solr 5.2.
          Hide
          dizzu333 Ovidiu Mihalcea added a comment -

          Any news when this would be solved? For now, Solr 5 seems much much more buggy then 4.x...

          Show
          dizzu333 Ovidiu Mihalcea added a comment - Any news when this would be solved? For now, Solr 5 seems much much more buggy then 4.x...
          Hide
          FabioBatSilva Fabio Batista da Silva added a comment -

          I ended working around this bug, i created a string field year_s only to be able to use it as group facet.

          Show
          FabioBatSilva Fabio Batista da Silva added a comment - I ended working around this bug, i created a string field year_s only to be able to use it as group facet.
          Hide
          varunthacker Varun Thacker added a comment -

          Test case which reproduces this problem.

          Currently group.facet is broken on all numeric non multi-valued fields.

          Show
          varunthacker Varun Thacker added a comment - Test case which reproduces this problem. Currently group.facet is broken on all numeric non multi-valued fields.
          Hide
          vdilipm@gmail.com Vishnu Mishra added a comment -

          I also have the same problem in solr 5.3.

          Show
          vdilipm@gmail.com Vishnu Mishra added a comment - I also have the same problem in solr 5.3.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          These bugs started with LUCENE-5666

          Show
          yseeley@gmail.com Yonik Seeley added a comment - These bugs started with LUCENE-5666
          Hide
          oschrenk Oliver Schrenk added a comment -

          Is there another way of faceting numeric data now?

          Show
          oschrenk Oliver Schrenk added a comment - Is there another way of faceting numeric data now?
          Hide
          smgadaleta Sabino Gadaleta added a comment -

          We have the same problem and it is preventing us from upgrading solr.

          Show
          smgadaleta Sabino Gadaleta added a comment - We have the same problem and it is preventing us from upgrading solr.
          Hide
          spyk Spyros Kapnissis added a comment -

          Same error with 5.3.1. Changing the grouping field to string type as mentioned above temporarily resolved the issue for me.

          Show
          spyk Spyros Kapnissis added a comment - Same error with 5.3.1. Changing the grouping field to string type as mentioned above temporarily resolved the issue for me.
          Hide
          antonkhoff Anton Khoff added a comment -

          I confirm we have the same issue starting from 5.1 and it still exists in 5.3.1. Sounds like a major one to me, hope it can be fixed soon

          Show
          antonkhoff Anton Khoff added a comment - I confirm we have the same issue starting from 5.1 and it still exists in 5.3.1. Sounds like a major one to me, hope it can be fixed soon
          Hide
          kunningham Kevin Cunningham added a comment -

          Changing the type to multi int allowed us to temporarily work around the issue.

          Show
          kunningham Kevin Cunningham added a comment - Changing the type to multi int allowed us to temporarily work around the issue.
          Hide
          PeterCiuffetti Peter Ciuffetti added a comment -

          The multi value work around is not available to me because I also need the fields affected by this bug to be sortable. And the string work around would only give me sortable values if the int's were fixed width (some of my int fields are, some are not).

          Show
          PeterCiuffetti Peter Ciuffetti added a comment - The multi value work around is not available to me because I also need the fields affected by this bug to be sortable. And the string work around would only give me sortable values if the int's were fixed width (some of my int fields are, some are not).
          Hide
          dsmiley David Smiley added a comment -

          Ok; you could use two fields then, one for sorting purposes, one for grouping purposes. This is a typical pattern – indexing a field different ways for different purposes.

          Show
          dsmiley David Smiley added a comment - Ok; you could use two fields then, one for sorting purposes, one for grouping purposes. This is a typical pattern – indexing a field different ways for different purposes.
          Hide
          gus_heck Gus Heck added a comment -

          Peter Ciuffetti I recently contributed SOLR-8113 which was specifically motivated by the need to sort when fields were multivalued. (by creating a copy that was single valued containing the first value).

          Show
          gus_heck Gus Heck added a comment - Peter Ciuffetti I recently contributed SOLR-8113 which was specifically motivated by the need to sort when fields were multivalued. (by creating a copy that was single valued containing the first value).
          Hide
          sebastien.cail S├ębastien Cail added a comment -

          Hi,
          I m having the same problem in SOLR 5.3.0

          Show
          sebastien.cail S├ębastien Cail added a comment - Hi, I m having the same problem in SOLR 5.3.0
          Hide
          kramachandran@commvault.com Karthik Ramachandran added a comment -

          Having the same issue in 5.5, will this be fixed any time soon?

          Show
          kramachandran@commvault.com Karthik Ramachandran added a comment - Having the same issue in 5.5, will this be fixed any time soon?
          Hide
          elyograg Shawn Heisey added a comment -

          A question for everyone having this problem ... is your numeric field defined with docValues="true"? Does your index contain multiple shards? The error message in the original report shows that Fabio's index is sharded, and the schema shows that the field in question did not have docValues.

          I suspect that if you add docValues, which will require a reindex, that the problem might go away. The problem also might only exist on a multi-shard (distributed) index.

          See SOLR-8088. The field I was trying to group on is a text field, not numeric, but docValues might also fix this problem. Since this issue is about a numeric field, there's no need to worry about things like lowercasing.

          Adding docValues makes sorting, faceting, and grouping use less memory, and also usually makes them faster. It also makes the index larger.

          Show
          elyograg Shawn Heisey added a comment - A question for everyone having this problem ... is your numeric field defined with docValues="true"? Does your index contain multiple shards? The error message in the original report shows that Fabio's index is sharded, and the schema shows that the field in question did not have docValues. I suspect that if you add docValues, which will require a reindex , that the problem might go away. The problem also might only exist on a multi-shard (distributed) index. See SOLR-8088 . The field I was trying to group on is a text field, not numeric, but docValues might also fix this problem. Since this issue is about a numeric field, there's no need to worry about things like lowercasing. Adding docValues makes sorting, faceting, and grouping use less memory, and also usually makes them faster. It also makes the index larger.
          Hide
          mjhilt Matt Hilt added a comment -

          We had this problem using Solr 5.1 on an index that was not sharded. The fields in question did not have docValues set however.

          Show
          mjhilt Matt Hilt added a comment - We had this problem using Solr 5.1 on an index that was not sharded . The fields in question did not have docValues set however.
          Hide
          FabioBatSilva Fabio Batista da Silva added a comment -

          IRC I tried docValues="true" and got the same results

          Show
          FabioBatSilva Fabio Batista da Silva added a comment - IRC I tried docValues="true" and got the same results
          Hide
          elyograg Shawn Heisey added a comment -

          Did you reindex? Just adding the parameter to the field definition is not enough.

          Show
          elyograg Shawn Heisey added a comment - Did you reindex? Just adding the parameter to the field definition is not enough.
          Hide
          FabioBatSilva Fabio Batista da Silva added a comment -

          I had fresh SOLR install

          Show
          FabioBatSilva Fabio Batista da Silva added a comment - I had fresh SOLR install
          Hide
          pcdev Matt Weber added a comment -

          group.facet also breaks range queries. I'm finding v5 almost non-usable.

          I tried setting docValues to true on the fields (and re-indexing), but it hasn't worked differently.

          The only workaround I found was using facet queries with multi-valued fields, but that doesn't help with everything.

          The work around doesn't apply to range facets.

          For example:

          This works...

          &facet.range=rounded_price&f.rounded_price.facet.range.start=0&f.rounded_price.facet.range.end=100&f.rounded_price.facet.range.gap=10&facet=on

          But simply adding "group.facet" fails...

          &facet.range=rounded_price&f.rounded_price.facet.range.start=0&f.rounded_price.facet.range.end=100&f.rounded_price.facet.range.gap=10&facet=on&group.facet=true&group.field=anyNumericField

          Show
          pcdev Matt Weber added a comment - group.facet also breaks range queries. I'm finding v5 almost non-usable. I tried setting docValues to true on the fields (and re-indexing), but it hasn't worked differently. The only workaround I found was using facet queries with multi-valued fields, but that doesn't help with everything. The work around doesn't apply to range facets. For example: This works... &facet.range=rounded_price&f.rounded_price.facet.range.start=0&f.rounded_price.facet.range.end=100&f.rounded_price.facet.range.gap=10&facet=on But simply adding "group.facet" fails... &facet.range=rounded_price&f.rounded_price.facet.range.start=0&f.rounded_price.facet.range.end=100&f.rounded_price.facet.range.gap=10&facet=on&group.facet=true&group.field=anyNumericField
          Hide
          sstults Scott Stults added a comment -

          SimpleFacets uses the insanity collector wrapper to return null docValues on grouping fields that are single-valued numerics. It looks like this also needs to be done on the facet field as well (when grouping). The attached patch first checks to see if the grouping field collector needs to be wrapped (that's what we've been doing) and then a second wrapper is applied if the facet field needs to be wrapped as well.

          The new patch includes the previously attached unit test (now working).

          Show
          sstults Scott Stults added a comment - SimpleFacets uses the insanity collector wrapper to return null docValues on grouping fields that are single-valued numerics. It looks like this also needs to be done on the facet field as well (when grouping). The attached patch first checks to see if the grouping field collector needs to be wrapped (that's what we've been doing) and then a second wrapper is applied if the facet field needs to be wrapped as well. The new patch includes the previously attached unit test (now working).
          Hide
          ncoult Nick Coult added a comment -

          Is this still a bug in Solr 6?

          Show
          ncoult Nick Coult added a comment - Is this still a bug in Solr 6?
          Hide
          antonkhoff Anton Khoff added a comment -

          And what about 6.1?

          Show
          antonkhoff Anton Khoff added a comment - And what about 6.1?
          Hide
          sstults Scott Stults added a comment -

          The patched test testSimpleGroupedFacet verifies that this is still an issue with 6.1. It fails with:

          Caused by: java.lang.IllegalStateException: unexpected docvalues type NUMERIC for field 'duration_i1' (expected=SORTED). Use UninvertingReader or index with docvalues.

          However, when SimpleFacets.java is also patched the test passes. So this appears to still be necessary in 6.1.

          Show
          sstults Scott Stults added a comment - The patched test testSimpleGroupedFacet verifies that this is still an issue with 6.1. It fails with: Caused by: java.lang.IllegalStateException: unexpected docvalues type NUMERIC for field 'duration_i1' (expected=SORTED). Use UninvertingReader or index with docvalues. However, when SimpleFacets.java is also patched the test passes. So this appears to still be necessary in 6.1.
          Hide
          ncoult Nick Coult added a comment -

          Can you supply your patch for 6.1?
          Thanks

          Show
          ncoult Nick Coult added a comment - Can you supply your patch for 6.1? Thanks
          Hide
          sstults Scott Stults added a comment -

          The patch uploaded in April works for me on the 6.1 branch. Is it not working for you?

          Show
          sstults Scott Stults added a comment - The patch uploaded in April works for me on the 6.1 branch. Is it not working for you?
          Hide
          ncoult Nick Coult added a comment -

          The patch did not cleanly apply but it does compile and run correctly, thanks!

          Show
          ncoult Nick Coult added a comment - The patch did not cleanly apply but it does compile and run correctly, thanks!
          Hide
          sstults Scott Stults added a comment -

          Robert Muir could you weigh in on the approach of the patch? I'd be happy to tweak it or take a completely different angle if that'll help close this issue.

          Show
          sstults Scott Stults added a comment - Robert Muir could you weigh in on the approach of the patch? I'd be happy to tweak it or take a completely different angle if that'll help close this issue.
          Hide
          mjhilt Matt Hilt added a comment -

          I have been testing this patch out on Solr 6.x. It does correct the problem (at least on 6.0.1), but only when the field does NOT have docValues enabled. Is this expected? Can the existing patch be extended to support docValues too, or is that a completely separate implementation?

          Show
          mjhilt Matt Hilt added a comment - I have been testing this patch out on Solr 6.x. It does correct the problem (at least on 6.0.1), but only when the field does NOT have docValues enabled. Is this expected? Can the existing patch be extended to support docValues too, or is that a completely separate implementation?
          Hide
          dpgove Dennis Gove added a comment -

          This patch applies cleanly to branch_6x.

          I did see the test fail before applying the change to SimpleFacets and then saw it pass after applying the change to SimpleFacets. Going to run through all the tests before committing this change.

          Show
          dpgove Dennis Gove added a comment - This patch applies cleanly to branch_6x. I did see the test fail before applying the change to SimpleFacets and then saw it pass after applying the change to SimpleFacets. Going to run through all the tests before committing this change.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 6e10e36216db9861530b4407866e292a89927a9e in lucene-solr's branch refs/heads/branch_6x from Dennis Gove
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6e10e36 ]

          SOLR-7495: Support Facet.field on a non-DocValued, single-value, int field

          Show
          jira-bot ASF subversion and git services added a comment - Commit 6e10e36216db9861530b4407866e292a89927a9e in lucene-solr's branch refs/heads/branch_6x from Dennis Gove [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6e10e36 ] SOLR-7495 : Support Facet.field on a non-DocValued, single-value, int field
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f9e3554838f3a43742928d11a7dcd9a8409e0c97 in lucene-solr's branch refs/heads/master from Dennis Gove
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9e3554 ]

          SOLR-7495: Support Facet.field on a non-DocValued, single-value, int field

          Show
          jira-bot ASF subversion and git services added a comment - Commit f9e3554838f3a43742928d11a7dcd9a8409e0c97 in lucene-solr's branch refs/heads/master from Dennis Gove [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9e3554 ] SOLR-7495 : Support Facet.field on a non-DocValued, single-value, int field
          Hide
          eqw3rty Eugene Tskhovrebov added a comment -

          AFAIS you can wrap any field into InsanityWrapper. What is the idea behind such strict check?

          if (sf != null && !sf.hasDocValues() && !sf.multiValued() && sf.getType().getNumericType() != null) {

          What about other field types (e.g., Numeric DocValued or Dates)?

          Show
          eqw3rty Eugene Tskhovrebov added a comment - AFAIS you can wrap any field into InsanityWrapper. What is the idea behind such strict check? if (sf != null && !sf.hasDocValues() && !sf.multiValued() && sf.getType().getNumericType() != null) { What about other field types (e.g., Numeric DocValued or Dates)?
          Hide
          sstults Scott Stults added a comment -

          Robert Muir added that line at the same time as the Insanity wrapper itself as part of LUCENE-5666, but I'll take a crack at an explanation. There's only a couple of cases outlined Insanity where we need to wrap the field, essentially returning null instead of the docValues. When the collector returns null the stored values of the field are used instead of docValues. Since stored values are slower than docValues we only want to wrap the particular field type that's problematic.

          Show
          sstults Scott Stults added a comment - Robert Muir added that line at the same time as the Insanity wrapper itself as part of LUCENE-5666 , but I'll take a crack at an explanation. There's only a couple of cases outlined Insanity where we need to wrap the field, essentially returning null instead of the docValues. When the collector returns null the stored values of the field are used instead of docValues. Since stored values are slower than docValues we only want to wrap the particular field type that's problematic.
          Hide
          dsmiley David Smiley added a comment -

          FieldCache "insanity" is when the same field is uninverted into memory multiple ways for different types (i.e. as a number and also as a string). The FieldCache is today also known as UninvertingReader. Obviously something to be avoided and signified possible Solr usage error. I recall it was easier to trigger this than nowadays.

          Show
          dsmiley David Smiley added a comment - FieldCache "insanity" is when the same field is uninverted into memory multiple ways for different types (i.e. as a number and also as a string). The FieldCache is today also known as UninvertingReader. Obviously something to be avoided and signified possible Solr usage error. I recall it was easier to trigger this than nowadays.

            People

            • Assignee:
              dpgove Dennis Gove
              Reporter:
              FabioBatSilva Fabio Batista da Silva
            • Votes:
              30 Vote for this issue
              Watchers:
              41 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development