Solr
  1. Solr
  2. SOLR-2976

stats.facet no longer works on single valued trie fields that don't use precision step

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.5
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      As reported on the mailing list, 3.5 introduced a regression that prevents single valued Trie fields that don't use precision steps (to add course grained terms) from being used in stats.facet.

      two immediately obvious problems...

      1) in 3.5 the stats component is checking if isTokenzed() is true for the field type (which is probably wise) but regardless of the precisionStep used, TrieField.isTokenized is hardcoded to return true

      2) the 3.5 stats faceting will fail if the FieldType is multivalued - it doesn't check if the SchemaField is configured to be single valued (overriding the FieldType)

      so even if a user has something like this in their schema...

      <fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" />
      <field name="ts" type="long" indexed="true" stored="true" required="true" multiValued="false" />
      

      ...stats.facet will not work.

      1. SOLR-2976_3.4_test.patch
        6 kB
        Hoss Man
      2. SOLR-2976.patch
        13 kB
        Robert Muir
      3. SOLR-2976.patch
        14 kB
        Hoss Man

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          FYI: doing some code skimming the current implications of this are:

          • QEC will unneccessarily fail to work if your uniqueKey is a precisionStep=0 TrieField
          • stats.facet will mistakenly refuse to facet on a multiValued=false precisionStep=0 TrieField

          Related thread: http://www.mail-archive.com/solr-user@lucene.apache.org/msg60073.html

          Show
          Hoss Man added a comment - FYI: doing some code skimming the current implications of this are: QEC will unneccessarily fail to work if your uniqueKey is a precisionStep=0 TrieField stats.facet will mistakenly refuse to facet on a multiValued=false precisionStep=0 TrieField Related thread: http://www.mail-archive.com/solr-user@lucene.apache.org/msg60073.html
          Hide
          Yonik Seeley added a comment -

          IIRC the meaning of isTokenized was taken from lucene long ago: "True if this field's value should be analyzed".
          Looking at the current uses of isTokenized in Solr, it's been a bit abused and actually may no longer be needed.

          Show
          Yonik Seeley added a comment - IIRC the meaning of isTokenized was taken from lucene long ago: "True if this field's value should be analyzed". Looking at the current uses of isTokenized in Solr, it's been a bit abused and actually may no longer be needed.
          Hide
          Uwe Schindler added a comment -

          Hi Hoss,

          in general the precisionStep is somehow inconsistent between Solr and Lucene. The problem is that precisionStep==0 is not defined at all. The minimium precision step in Lucene is 1 and means lot's of terms per distinct value. What Solr defines as precisionStep 0 is in Lucene everything >= 64 (for longs) or >= 32 for ints.

          In general it is confusing that we have two precSteps. I would prefer it in this issue to clean this up and make the solr schema simply allow a symbolic constant for the precision step (as 0 makes no sense and infinite is not a valid number in Integer.valueOf). How about precisionStep="infinite", because that would be consistent with Lucene. For backwards compatibility, 0 could still be supported, but Lucene throws IAE.

          Show
          Uwe Schindler added a comment - Hi Hoss, in general the precisionStep is somehow inconsistent between Solr and Lucene. The problem is that precisionStep==0 is not defined at all. The minimium precision step in Lucene is 1 and means lot's of terms per distinct value. What Solr defines as precisionStep 0 is in Lucene everything >= 64 (for longs) or >= 32 for ints. In general it is confusing that we have two precSteps. I would prefer it in this issue to clean this up and make the solr schema simply allow a symbolic constant for the precision step (as 0 makes no sense and infinite is not a valid number in Integer.valueOf). How about precisionStep="infinite", because that would be consistent with Lucene. For backwards compatibility, 0 could still be supported, but Lucene throws IAE.
          Hide
          Uwe Schindler added a comment -

          IIRC the meaning of isTokenized was taken from lucene long ago: "True if this field's value should be analyzed". Looking at the current uses of isTokenized in Solr, it's been a bit abused and actually may no longer be needed.

          It is often used in solr as "multiValued", which is a separate property of a field. +1 to remove is Tokenized (especially, as Lucene no longer differentiates between tokenized and not tokenized. Every field in Lucene trunk has a TokenStream/AttributeSource, although it returns only one token.

          Show
          Uwe Schindler added a comment - IIRC the meaning of isTokenized was taken from lucene long ago: "True if this field's value should be analyzed". Looking at the current uses of isTokenized in Solr, it's been a bit abused and actually may no longer be needed. It is often used in solr as "multiValued", which is a separate property of a field. +1 to remove is Tokenized (especially, as Lucene no longer differentiates between tokenized and not tokenized. Every field in Lucene trunk has a TokenStream/AttributeSource, although it returns only one token.
          Hide
          Yonik Seeley added a comment -

          precisionStep="infinite"

          Heh. Try explaining that one to users

          "0 disables the more-tokens-for-faster-range-queries feature" seems pretty understandable to most people.

          Show
          Yonik Seeley added a comment - precisionStep="infinite" Heh. Try explaining that one to users "0 disables the more-tokens-for-faster-range-queries feature" seems pretty understandable to most people.
          Hide
          Hoss Man added a comment -

          it's been a bit abused and actually may no longer be needed.

          Good point ... other then the two uses i mentioned, i think LukeRequestHandler is the only other place (outside of FieldType) in Solr that even cares about FieldType.isTokenized()

          (other things internally to FieldType care about the TOKENIZED property, but even that isn't used by much other then TextField)

          Show
          Hoss Man added a comment - it's been a bit abused and actually may no longer be needed. Good point ... other then the two uses i mentioned, i think LukeRequestHandler is the only other place (outside of FieldType) in Solr that even cares about FieldType.isTokenized() (other things internally to FieldType care about the TOKENIZED property, but even that isn't used by much other then TextField)
          Hide
          Uwe Schindler added a comment -

          I just prefer a non-numeric. And even LucidImagination-people dont understand this (I had a discussion with one of your employees who did not know). When I explained it to him what precision step means, he said:

          • Document it in the schema / Lucene NRQ javadocs
          • Document it in the Wiki
          • rename the 0 as it makes no sense
          Show
          Uwe Schindler added a comment - I just prefer a non-numeric. And even LucidImagination-people dont understand this (I had a discussion with one of your employees who did not know). When I explained it to him what precision step means, he said: Document it in the schema / Lucene NRQ javadocs Document it in the Wiki rename the 0 as it makes no sense
          Hide
          Hoss Man added a comment -

          in general the precisionStep is somehow inconsistent between Solr and Lucene

          it's not inconsistent, Solr's TrieField uses Integer.MAX_VALUE correctly, it just happily accepts config values <=0 as being equivalent to specifying Integer.MAX_VALUE (the javadocs for TrieField don't even say you can specify "0" ... they say "Note that if you use a precisionStep of 32 for int/float and 64 for long/double/date, then multiple terms will not be generated") .. if you want to add yet another symbolic constant for Integer.MAX_VALUE i'm fine with that, but please open a new issue – it's totally orthogonal to what we're talking about here.

          Show
          Hoss Man added a comment - in general the precisionStep is somehow inconsistent between Solr and Lucene it's not inconsistent, Solr's TrieField uses Integer.MAX_VALUE correctly, it just happily accepts config values <=0 as being equivalent to specifying Integer.MAX_VALUE (the javadocs for TrieField don't even say you can specify "0" ... they say "Note that if you use a precisionStep of 32 for int/float and 64 for long/double/date, then multiple terms will not be generated") .. if you want to add yet another symbolic constant for Integer.MAX_VALUE i'm fine with that, but please open a new issue – it's totally orthogonal to what we're talking about here.
          Hide
          Uwe Schindler added a comment -

          Sorry Hoss, this annoys me since long time and this issue seemed to be the right place to complain about precStep==0, which makes no sense (sorry, Yonik).

          Show
          Uwe Schindler added a comment - Sorry Hoss, this annoys me since long time and this issue seemed to be the right place to complain about precStep==0, which makes no sense (sorry, Yonik).
          Hide
          Yonik Seeley added a comment -

          No need to apologize for disagreeing, but I still think "0" is fine.

          And if we're pushing for consistency, perhaps Lucene should change to something more easily understood as "disable this feature".

          Show
          Yonik Seeley added a comment - No need to apologize for disagreeing, but I still think "0" is fine. And if we're pushing for consistency, perhaps Lucene should change to something more easily understood as "disable this feature".
          Hide
          Uwe Schindler added a comment -

          I would agree to also use a constant in Lucene (that maps internally to Integer.MAX_VALUE).

          Show
          Uwe Schindler added a comment - I would agree to also use a constant in Lucene (that maps internally to Integer.MAX_VALUE).
          Hide
          Hoss Man added a comment -

          Seriously guys: start a new fucking issue if you care so much, and debate the optimal API/docs/sample configs for precisionStep there.

          whether a new symbolic constant is added really has ZERO bearing on this issue, which is about whether or not TrieField.isTokenized() is broken.

          (this is what the "related issues" Jira link type is for)

          Show
          Hoss Man added a comment - Seriously guys: start a new fucking issue if you care so much, and debate the optimal API/docs/sample configs for precisionStep there. whether a new symbolic constant is added really has ZERO bearing on this issue, which is about whether or not TrieField.isTokenized() is broken. (this is what the "related issues" Jira link type is for)
          Hide
          Hoss Man added a comment -

          I started looking into this today and realized there are additional problems with the stats faceting code changed in 3.5 as it relates to tried fields and the original problem report. Updating the summary/description to expand the scope

          Show
          Hoss Man added a comment - I started looking into this today and realized there are additional problems with the stats faceting code changed in 3.5 as it relates to tried fields and the original problem report. Updating the summary/description to expand the scope
          Hide
          Hoss Man added a comment -

          SOLR-2976_3.4_test.patch is a simple test patch against 3.4 showing the basics of what use to work when trying to do stats faceting on trie fields. If you apply this patch to 3.5 or the 3x branch (requires massaging as the line numbers have changed heavily) you'll see the test fail.

          SOLR-2976.patch shows my attempt at fixing some of these problems on trunk...

          1) fix TrieField.isTokenized to be based on precision step
          2) test TrieField.isTokenized
          3) fix StatsComponent to look at the SchemaField not just the FieldType
          4) make StatsComponentTest give better errors
          5) make StatsComponentTest try to use stats.facet on a trie field with one term per value

          But doing this has exposed a new bug i don't fully understand yet: Test now throws an NFE that seems to be coming from the code for generating the stat's facets on a trie field – but it is dependent on which field type we are generating stats over. If the stats are against a trie field, then the faceting on a trie field fails – but if the stats are on a simple numeric, then the faceting on a trie field passes.

          Need to wade into this more later...

              [junit] Testcase: testStats(org.apache.solr.handler.component.StatsComponentTest):	Caused an ERROR
              [junit] exception with field: stats_ti
              [junit] java.lang.RuntimeException: exception with field: stats_ti
              [junit] 	at org.apache.solr.handler.component.StatsComponentTest.testStats(StatsComponentTest.java:68)
              [junit] 	at org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:528)
              [junit] 	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
              [junit] 	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
              [junit] Caused by: java.lang.RuntimeException: Exception during query
              [junit] 	at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:267)
              [junit] 	at org.apache.solr.handler.component.StatsComponentTest.doTestFacetStatisticsResult(StatsComponentTest.java:275)
              [junit] 	at org.apache.solr.handler.component.StatsComponentTest.testStats(StatsComponentTest.java:65)
              [junit] Caused by: java.lang.NumberFormatException: For input string: "N"
              [junit] 	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
              [junit] 	at java.lang.Integer.parseInt(Integer.java:449)
              [junit] 	at java.lang.Integer.parseInt(Integer.java:499)
              [junit] 	at org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:303)
              [junit] 	at org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:294)
              [junit] 	at org.apache.solr.schema.TrieField.toInternal(TrieField.java:324)
              [junit] 	at org.apache.solr.request.UnInvertedField.getStats(UnInvertedField.java:609)
              [junit] 	at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:235)
              [junit] 	at org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:211)
              [junit] 	at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:70)
          
          
          Show
          Hoss Man added a comment - SOLR-2976 _3.4_test.patch is a simple test patch against 3.4 showing the basics of what use to work when trying to do stats faceting on trie fields. If you apply this patch to 3.5 or the 3x branch (requires massaging as the line numbers have changed heavily) you'll see the test fail. SOLR-2976 .patch shows my attempt at fixing some of these problems on trunk... 1) fix TrieField.isTokenized to be based on precision step 2) test TrieField.isTokenized 3) fix StatsComponent to look at the SchemaField not just the FieldType 4) make StatsComponentTest give better errors 5) make StatsComponentTest try to use stats.facet on a trie field with one term per value But doing this has exposed a new bug i don't fully understand yet: Test now throws an NFE that seems to be coming from the code for generating the stat's facets on a trie field – but it is dependent on which field type we are generating stats over. If the stats are against a trie field, then the faceting on a trie field fails – but if the stats are on a simple numeric, then the faceting on a trie field passes. Need to wade into this more later... [junit] Testcase: testStats(org.apache.solr.handler.component.StatsComponentTest): Caused an ERROR [junit] exception with field: stats_ti [junit] java.lang.RuntimeException: exception with field: stats_ti [junit] at org.apache.solr.handler.component.StatsComponentTest.testStats(StatsComponentTest.java:68) [junit] at org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:528) [junit] at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) [junit] at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) [junit] Caused by: java.lang.RuntimeException: Exception during query [junit] at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:267) [junit] at org.apache.solr.handler.component.StatsComponentTest.doTestFacetStatisticsResult(StatsComponentTest.java:275) [junit] at org.apache.solr.handler.component.StatsComponentTest.testStats(StatsComponentTest.java:65) [junit] Caused by: java.lang.NumberFormatException: For input string: "N" [junit] at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) [junit] at java.lang. Integer .parseInt( Integer .java:449) [junit] at java.lang. Integer .parseInt( Integer .java:499) [junit] at org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:303) [junit] at org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:294) [junit] at org.apache.solr.schema.TrieField.toInternal(TrieField.java:324) [junit] at org.apache.solr.request.UnInvertedField.getStats(UnInvertedField.java:609) [junit] at org.apache.solr.handler.component.SimpleStats.getStatsFields(StatsComponent.java:235) [junit] at org.apache.solr.handler.component.SimpleStats.getStatsCounts(StatsComponent.java:211) [junit] at org.apache.solr.handler.component.StatsComponent.process(StatsComponent.java:70)
          Hide
          Hoss Man added a comment -

          somehow forgot to ever link this issue to the one that seems to have caused it

          Show
          Hoss Man added a comment - somehow forgot to ever link this issue to the one that seems to have caused it
          Hide
          Hoss Man added a comment -

          i haven't had any more time to try and make sense of this, and don't anticipate doing so in the near future.

          giving to ryan since he worked on SOLR-1023 in the hopes that it's something he understands and can help bang out a fix for easily.

          Show
          Hoss Man added a comment - i haven't had any more time to try and make sense of this, and don't anticipate doing so in the near future. giving to ryan since he worked on SOLR-1023 in the hopes that it's something he understands and can help bang out a fix for easily.
          Hide
          yuanyun.cn added a comment -

          Hit this problem recently.
          To fix this problem. and support facet search on this field, I have to create another field, with precisionStep="2147483647"(Integer,MAX_VALUE), this is not good, as it takes more disk size, and it's hard to explain to customers why we need this field.

          So do we have plan to fix this problem? Thanks

          Show
          yuanyun.cn added a comment - Hit this problem recently. To fix this problem. and support facet search on this field, I have to create another field, with precisionStep="2147483647"(Integer,MAX_VALUE), this is not good, as it takes more disk size, and it's hard to explain to customers why we need this field. So do we have plan to fix this problem? Thanks
          Hide
          Robert Muir added a comment -

          Its also the case that if precisionStep != 0, faceting on a single-valued numeric field builds an UninvertedField (which is unnecessary, as the fieldcache can handle this just fine).

          Show
          Robert Muir added a comment - Its also the case that if precisionStep != 0, faceting on a single-valued numeric field builds an UninvertedField (which is unnecessary, as the fieldcache can handle this just fine).
          Hide
          Yonik Seeley added a comment -

          Its also the case that if precisionStep != 0, faceting on a single-valued numeric field builds an UninvertedField (which is unnecessary, as the fieldcache can handle this just fine).

          That shouldn't be the case. The current algorithms check Solr's idea of single valued vs multi-valued - it doesn't matter how many tokens are indexed per value.

          Show
          Yonik Seeley added a comment - Its also the case that if precisionStep != 0, faceting on a single-valued numeric field builds an UninvertedField (which is unnecessary, as the fieldcache can handle this just fine). That shouldn't be the case. The current algorithms check Solr's idea of single valued vs multi-valued - it doesn't matter how many tokens are indexed per value.
          Hide
          Robert Muir added a comment -

          Yonik: Ill port over my test. But i think this is the piece of the code that causes it in SimpleFacets:

          boolean multiToken = sf.multiValued() || ft.multiValuedFieldCache();
          
          if (TrieField.getMainValuePrefix(ft) != null) {
            // A TrieField with multiple parts indexed per value... currently only
            // UnInvertedField can handle this case, so force it's use.
            enumMethod = false;
            multiToken = true;
          }
          

          This second "if" I think causes the problem? It only returns null if precisionStep is 0:

          if (trie.precisionStep  == Integer.MAX_VALUE)
            return null;
          
          Show
          Robert Muir added a comment - Yonik: Ill port over my test. But i think this is the piece of the code that causes it in SimpleFacets: boolean multiToken = sf.multiValued() || ft.multiValuedFieldCache(); if (TrieField.getMainValuePrefix(ft) != null ) { // A TrieField with multiple parts indexed per value... currently only // UnInvertedField can handle this case , so force it's use. enumMethod = false ; multiToken = true ; } This second "if" I think causes the problem? It only returns null if precisionStep is 0: if (trie.precisionStep == Integer .MAX_VALUE) return null ;
          Hide
          Robert Muir added a comment -

          Sorry Ryan, I didnt mean to assign myself. My browser just went psycho for a bit!

          Show
          Robert Muir added a comment - Sorry Ryan, I didnt mean to assign myself. My browser just went psycho for a bit!
          Hide
          Yonik Seeley added a comment -

          Verified the problem.
          Just do:

          http://localhost:8983/solr/select?q=*:*&facet=true&facet.field=foo_ti
          

          And then observe the log:

          Dec 19, 2012 9:00:12 PM org.apache.solr.request.UnInvertedField <init>
          INFO: UnInverted multi-valued field {field=foo_ti,memSize=4288,tindexSize=0,time=0,phase1=0,nTerms=0,bigTerms=0,termInstances=0,uses=0}
          
          Show
          Yonik Seeley added a comment - Verified the problem. Just do: http: //localhost:8983/solr/select?q=*:*&facet= true &facet.field=foo_ti And then observe the log: Dec 19, 2012 9:00:12 PM org.apache.solr.request.UnInvertedField <init> INFO: UnInverted multi-valued field {field=foo_ti,memSize=4288,tindexSize=0,time=0,phase1=0,nTerms=0,bigTerms=0,termInstances=0,uses=0}
          Hide
          Yonik Seeley added a comment -

          Does this faceting limitation simply date back to before trie fields with precision step > 0 couldn't use the fieldCache? Was introduced over 3 years ago (SOLR-1492). Maybe we just forgot to remove it...

          Show
          Yonik Seeley added a comment - Does this faceting limitation simply date back to before trie fields with precision step > 0 couldn't use the fieldCache? Was introduced over 3 years ago ( SOLR-1492 ). Maybe we just forgot to remove it...
          Hide
          Ryan McKinley added a comment -

          did not know this was assigned to me.... i'll step out since I don't fully understand what is happening

          Show
          Ryan McKinley added a comment - did not know this was assigned to me.... i'll step out since I don't fully understand what is happening
          Hide
          Robert Muir added a comment -

          Its not like the code comment is wrong, it just seems like we could do stuff more efficiently.

          I commented on this issue (maybe its unrelated, but it seems to also affect the stats thing too), because i was surprised to see
          the uninverting multi-valued field for a single-valued trie field when running a test.

          Show
          Robert Muir added a comment - Its not like the code comment is wrong, it just seems like we could do stuff more efficiently. I commented on this issue (maybe its unrelated, but it seems to also affect the stats thing too), because i was surprised to see the uninverting multi-valued field for a single-valued trie field when running a test.
          Hide
          Adrien Grand added a comment -

          if precisionStep != 0, faceting on a single-valued numeric field builds an UninvertedField

          I think the last commits on SOLR-3855 fix it (they even make faceting use the numeric field caches instead of the terms index).

          Show
          Adrien Grand added a comment - if precisionStep != 0, faceting on a single-valued numeric field builds an UninvertedField I think the last commits on SOLR-3855 fix it (they even make faceting use the numeric field caches instead of the terms index).
          Hide
          Robert Muir added a comment -

          As adrien mentioned, the underlying issue is fixed (stats.facet implemented differently).

          However, its still bogus that this fieldtype returns true for isTokenized(), and that it has a crazy custom attribute-wrapping TrieTokenizerFactory that is totally unnecessary: at index-time createField() is just using IntField/FloatField/etc, for range-queries the analyzer is also not used (it forms getRangeQuery), and for term-queries getFieldQuery already does the right thing.

          This patch removes this stuff.

          Show
          Robert Muir added a comment - As adrien mentioned, the underlying issue is fixed (stats.facet implemented differently). However, its still bogus that this fieldtype returns true for isTokenized(), and that it has a crazy custom attribute-wrapping TrieTokenizerFactory that is totally unnecessary: at index-time createField() is just using IntField/FloatField/etc, for range-queries the analyzer is also not used (it forms getRangeQuery), and for term-queries getFieldQuery already does the right thing. This patch removes this stuff.
          Hide
          Yonik Seeley added a comment -

          +1, looks like legacy stuff that's no longer needed/used.

          Show
          Yonik Seeley added a comment - +1, looks like legacy stuff that's no longer needed/used.
          Hide
          Uwe Schindler added a comment -

          +1, please remove useless TrieTokenizer! The only backside is, that you can no longer "inspect trie tokens" with AnalysisRequestHandler, but that's not really an issue, because numeric terms are an implementation detail I just used it sometimes to demonstrate users how trie terms look like.

          From ElasticSearch I know that they also added this Tokenizer (Adrien did it), but there it was done for highlighting. If this is the case in Solr, too, we should keep it. How is highlighting affected - or does highölighting on NumericFields does not work at all in Solr?

          Show
          Uwe Schindler added a comment - +1, please remove useless TrieTokenizer! The only backside is, that you can no longer "inspect trie tokens" with AnalysisRequestHandler, but that's not really an issue, because numeric terms are an implementation detail I just used it sometimes to demonstrate users how trie terms look like. From ElasticSearch I know that they also added this Tokenizer (Adrien did it), but there it was done for highlighting. If this is the case in Solr, too, we should keep it. How is highlighting affected - or does highölighting on NumericFields does not work at all in Solr?
          Hide
          Robert Muir added a comment -

          Highlighting NumericFields is disabled in solr. This patch is not related to that.

              // TODO: Currently in trunk highlighting numeric fields is broken (Lucene) -
              // so we disable them until fixed (see LUCENE-3080)!
              // BEGIN: Hack
              final SchemaField schemaField = schema.getFieldOrNull(fieldName);
              if (schemaField != null && (
                (schemaField.getType() instanceof org.apache.solr.schema.TrieField) ||
                (schemaField.getType() instanceof org.apache.solr.schema.TrieDateField)
              )) return;
              // END: Hack
          
          Show
          Robert Muir added a comment - Highlighting NumericFields is disabled in solr. This patch is not related to that. // TODO: Currently in trunk highlighting numeric fields is broken (Lucene) - // so we disable them until fixed (see LUCENE-3080)! // BEGIN: Hack final SchemaField schemaField = schema.getFieldOrNull(fieldName); if (schemaField != null && ( (schemaField.getType() instanceof org.apache.solr.schema.TrieField) || (schemaField.getType() instanceof org.apache.solr.schema.TrieDateField) )) return ; // END: Hack

            People

            • Assignee:
              Unassigned
              Reporter:
              Hoss Man
            • Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Development