Lucene - Core
  1. Lucene - Core
  2. LUCENE-2073

Document issues involved in building your index with one jdk version and then searching/updating with another

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.9, 5.0
    • Component/s: core/index
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      I think this needs to go in something of a permenant spot - this isn't a one time release type issues - its going to present over multiple release.

      If there is nothing we can do here, then we just have to do the best we can -
      such as a prominent notice alerting that if you transition JVM's between building and searching the index and you are using or doing X, things will break.

      We should put this in a spot that is always pretty visible - perhaps even a new readme file titlted something like IndexBackwardCompatibility or something, to which we can add other tips and gotchyas as they come up. Or MaintainingIndicesAcrossVersions, or FancyWhateverGetsYourAttentionAboutUpgradingStuff. Or a permanent entry/sticky entry at the top of Changes.

      1. stdAnalyzerTest.java
        2 kB
        Robert Muir
      2. LUCENE-2073.patch
        0.8 kB
        Robert Muir
      3. LUCENE-2073.patch
        1.0 kB
        Robert Muir
      4. LUCENE-2073.patch
        2 kB
        Robert Muir
      5. LUCENE-2073.patch
        2 kB
        Robert Muir

        Activity

        Hide
        Uwe Schindler added a comment -

        Move issue to Lucene 4.9.

        Show
        Uwe Schindler added a comment - Move issue to Lucene 4.9.
        Hide
        Steve Rowe added a comment -

        Bulk move 4.4 issues to 4.5 and 5.0

        Show
        Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
        Hide
        Steve Rowe added a comment -

        AFAICT, lucene/JRE_VERION_MIGRATION.txt doesn't need any modifications for the 4.1 release.

        Show
        Steve Rowe added a comment - AFAICT, lucene/JRE_VERION_MIGRATION.txt doesn't need any modifications for the 4.1 release.
        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 cleanup of 4.0-ALPHA / 4.0 Jira versioning. all bulk edited issues have hoss20120711-bulk-40-change in a comment

        Show
        Hoss Man added a comment - bulk cleanup of 4.0-ALPHA / 4.0 Jira versioning. all bulk edited issues have hoss20120711-bulk-40-change in a comment
        Hide
        Hoss Man added a comment -

        rmuir already wrote a doc on this back in 2009, not sure why it was the jira was left open.

        rmuir: can you resolve if you think we're good here, or update with what you think is still needed otherwise?

        Show
        Hoss Man added a comment - rmuir already wrote a doc on this back in 2009, not sure why it was the jira was left open. rmuir: can you resolve if you think we're good here, or update with what you think is still needed otherwise?
        Hide
        Robert Muir added a comment -

        Cool, we can do something similar in 3.1

        While it seems crazy, like these issues affect no one, someone told me today about relying upon broken unicode 4 behavior in lucene for chinese tokenization....!

        Show
        Robert Muir added a comment - Cool, we can do something similar in 3.1 While it seems crazy, like these issues affect no one, someone told me today about relying upon broken unicode 4 behavior in lucene for chinese tokenization....!
        Hide
        Mark Miller added a comment -

        Okay - popped it to 3.1 to ensure we look at this again.

        Show
        Mark Miller added a comment - Okay - popped it to 3.1 to ensure we look at this again.
        Hide
        Robert Muir added a comment -

        Committed revision 881466.

        should we keep the issue open Mark, or close it?
        I think we will potentially have some specialized problems in 3.1 also... (due to fixing unicode 4/suppl characters)

        Show
        Robert Muir added a comment - Committed revision 881466. should we keep the issue open Mark, or close it? I think we will potentially have some specialized problems in 3.1 also... (due to fixing unicode 4/suppl characters)
        Hide
        Mark Miller added a comment -

        Looks great! +1

        Show
        Mark Miller added a comment - Looks great! +1
        Hide
        Uwe Schindler added a comment -

        +1, ok

        Show
        Uwe Schindler added a comment - +1, ok
        Hide
        Robert Muir added a comment -

        guys I would like to commit this file soon, let me know if you see any issues with it.

        I think this additional verbage i added about "basic latin" is safe, the only properties that have changed even up to unicode 5.1 are minor changes to bidirectional properties.
        This only affects rendering/layout.

        Show
        Robert Muir added a comment - guys I would like to commit this file soon, let me know if you see any issues with it. I think this additional verbage i added about "basic latin" is safe, the only properties that have changed even up to unicode 5.1 are minor changes to bidirectional properties. This only affects rendering/layout.
        Hide
        Robert Muir added a comment -

        i added the following:

        In general, whether or not you need to re-index largely depends upon the data that
        you are searching, and what was changed in any given Unicode version. For example,
        if you are completely sure that your content is limited to the "Basic Latin" range
        of Unicode, you can safely ignore this.

        Show
        Robert Muir added a comment - i added the following: In general, whether or not you need to re-index largely depends upon the data that you are searching, and what was changed in any given Unicode version. For example, if you are completely sure that your content is limited to the "Basic Latin" range of Unicode, you can safely ignore this.
        Hide
        Robert Muir added a comment -

        Uwe, ok, I am currently trying to come up with a way to word this.

        Unknowns like the soft hyphen thing and other things word processors, etc might do make me really cautious to say something like this...
        I don't want someone to unnecessarily reindex, but on the other hand, I don't want to see bug report or whatever either.

        Show
        Robert Muir added a comment - Uwe, ok, I am currently trying to come up with a way to word this. Unknowns like the soft hyphen thing and other things word processors, etc might do make me really cautious to say something like this... I don't want someone to unnecessarily reindex, but on the other hand, I don't want to see bug report or whatever either.
        Hide
        Uwe Schindler added a comment -

        Text looks good, maybe we should still add the "basic latin as on your keyboard".

        Show
        Uwe Schindler added a comment - Text looks good, maybe we should still add the "basic latin as on your keyboard".
        Hide
        Robert Muir added a comment -

        the crappy test script i wrote to confirm the lowercasing behavior.
        maybe we need it again if we go to java 1.7 in this decade, or maybe i screwed something up

        Show
        Robert Muir added a comment - the crappy test script i wrote to confirm the lowercasing behavior. maybe we need it again if we go to java 1.7 in this decade, or maybe i screwed something up
        Hide
        Robert Muir added a comment -

        very happy to add new verbage here mentioning that StandardAnalyzer is ok.

        Show
        Robert Muir added a comment - very happy to add new verbage here mentioning that StandardAnalyzer is ok.
        Hide
        Robert Muir added a comment -

        Hi, I completely validated. StandardAnalyzer is ok. none of the casing changed for any previous [:letter:] characters from Unicode 3 in Unicode 4.

        I'll work on adding more explanation

        Show
        Robert Muir added a comment - Hi, I completely validated. StandardAnalyzer is ok. none of the casing changed for any previous [:letter:] characters from Unicode 3 in Unicode 4. I'll work on adding more explanation
        Hide
        Uwe Schindler added a comment -

        Of course, one never knows, I feel like i remember Microsoft Word creating strange hyphens and smart quotes automatically...

        It is the same strange soft hyphen we talked about before... Normally you should simply remove it during indexing using a CharFilter (I do this when indexing word documents and so on).

        Show
        Uwe Schindler added a comment - Of course, one never knows, I feel like i remember Microsoft Word creating strange hyphens and smart quotes automatically... It is the same strange soft hyphen we talked about before... Normally you should simply remove it during indexing using a CharFilter (I do this when indexing word documents and so on).
        Hide
        Robert Muir added a comment -

        > I am pretty sure StandardAnalyzer is ok actually now.

        Good news! Thanks for performing that analysis.

        Doh! this case pair stability policy was not introduced until 5.0, so to validate, i must do further analysis
        ref: "unicode back compat policy": http://www.unicode.org/policies/stability_policy.html

        Show
        Robert Muir added a comment - > I am pretty sure StandardAnalyzer is ok actually now. Good news! Thanks for performing that analysis. Doh! this case pair stability policy was not introduced until 5.0, so to validate, i must do further analysis ref: "unicode back compat policy": http://www.unicode.org/policies/stability_policy.html
        Hide
        Mark Miller added a comment - - edited

        if you are using "Basic Latin" as exists on your keyboard, you might be ok.

        Heh - well if thats the strongest you would say that, sounds like its not very containable. Perhaps we just put that?

        edit

        Yes, word def uses a couple funky things by default with hyphens and quotes - ran into that before. But I think its somewhat up to you to know that. If you are getting your text from another application, than you don't likely properly know you have latin1 stuff. But some people will know - in the newspaper biz, we use pre processing filters to map anything outside of latin1 to latin1 - else remove it. If you don't know your source text well enough, then yes, all bets are off.

        Show
        Mark Miller added a comment - - edited if you are using "Basic Latin" as exists on your keyboard, you might be ok. Heh - well if thats the strongest you would say that, sounds like its not very containable. Perhaps we just put that? edit Yes, word def uses a couple funky things by default with hyphens and quotes - ran into that before. But I think its somewhat up to you to know that. If you are getting your text from another application, than you don't likely properly know you have latin1 stuff. But some people will know - in the newspaper biz, we use pre processing filters to map anything outside of latin1 to latin1 - else remove it. If you don't know your source text well enough, then yes, all bets are off.
        Hide
        Marvin Humphrey added a comment -

        > I am pretty sure StandardAnalyzer is ok actually now.

        Good news! Thanks for performing that analysis.

        Show
        Marvin Humphrey added a comment - > I am pretty sure StandardAnalyzer is ok actually now. Good news! Thanks for performing that analysis.
        Hide
        Robert Muir added a comment -

        Mark good point, if you are using "Basic Latin" as exists on your keyboard, you might be ok.

        Of course, one never knows, I feel like i remember Microsoft Word creating strange hyphens and smart quotes automatically...

        I'd love to contain it, if you have some suggested verbage lets put it in there.

        Show
        Robert Muir added a comment - Mark good point, if you are using "Basic Latin" as exists on your keyboard, you might be ok. Of course, one never knows, I feel like i remember Microsoft Word creating strange hyphens and smart quotes automatically... I'd love to contain it, if you have some suggested verbage lets put it in there.
        Hide
        Robert Muir added a comment -

        I am pretty sure StandardAnalyzer is ok actually now.
        The only time it uses hardcoded ranges is for the CJK definition:
        and the following UnicodeSet is the empty set (0 codepoints):

        [[\u3100-\u312f\u3040-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3300-\u337f\u3400-\u4dbf\u4e00-\u9fff\uf900-\ufaff\uff65-\uff9f]&[:Case_Sensitive=True:]]
        

        WikipediaTokenizer, probably not ok

        Show
        Robert Muir added a comment - I am pretty sure StandardAnalyzer is ok actually now. The only time it uses hardcoded ranges is for the CJK definition: and the following UnicodeSet is the empty set (0 codepoints): [[\u3100-\u312f\u3040-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3300-\u337f\u3400-\u4dbf\u4e00-\u9fff\uf900-\ufaff\uff65-\uff9f]&[:Case_Sensitive=True:]] WikipediaTokenizer, probably not ok
        Hide
        Mark Miller added a comment -

        Okay, fair enough - in the end I do think we want to err on the side of caution - losing terms/docs in the index can be disastrous for some. Can we contain the statement at all though? What if you are just working with essentially ascii text? Basic English chars? That type of thing ... perhaps saying something to the effect of, in many/some cases, a user might not be affected, but if you need to be sure, you must reindex?

        Show
        Mark Miller added a comment - Okay, fair enough - in the end I do think we want to err on the side of caution - losing terms/docs in the index can be disastrous for some. Can we contain the statement at all though? What if you are just working with essentially ascii text? Basic English chars? That type of thing ... perhaps saying something to the effect of, in many/some cases, a user might not be affected, but if you need to be sure, you must reindex?
        Hide
        Marvin Humphrey added a comment -

        > are you sure? StandardAnalyzer uses LowerCaseFilter,

        No, I'm not sure. I was confusing StandardAnalyzer and StandardTokenizer.

        I still think that there are a lot of people who don't need to reindex,
        because, for example, their entire corpus is limited to Latin-1 code points.

        Conversely, the people most likely to be affected are the people most likely
        to be on the lookout for this kind of think. I think it's important to
        reach this group, without unduly alarming those who don't really need to
        reindex. Reindexing is a huge pain for some installations.

        Show
        Marvin Humphrey added a comment - > are you sure? StandardAnalyzer uses LowerCaseFilter, No, I'm not sure. I was confusing StandardAnalyzer and StandardTokenizer. I still think that there are a lot of people who don't need to reindex, because, for example, their entire corpus is limited to Latin-1 code points. Conversely, the people most likely to be affected are the people most likely to be on the lookout for this kind of think. I think it's important to reach this group, without unduly alarming those who don't really need to reindex. Reindexing is a huge pain for some installations.
        Hide
        Robert Muir added a comment -

        Mark, but here is the crux of the issue:

        While i think casing property is normative and should not change, new characters can be introduced with new casing properties.
        This of course should not affect Simple/StopAnalyzer, but may affect StandardAnalyzer.

        The reason is that StandardTokenizer contains hardcoded (sometimes oversized) ranges that may include some characters that were previously unassigned in Unicode 3.
        If they are assigned in Unicode 4, with a casing property, then this means for lucene, they were indexed in uppercase in 1.4 but lowercase in 1.5... i hope this makes sense.

        Show
        Robert Muir added a comment - Mark, but here is the crux of the issue: While i think casing property is normative and should not change, new characters can be introduced with new casing properties. This of course should not affect Simple/StopAnalyzer, but may affect StandardAnalyzer. The reason is that StandardTokenizer contains hardcoded (sometimes oversized) ranges that may include some characters that were previously unassigned in Unicode 3. If they are assigned in Unicode 4, with a casing property, then this means for lucene, they were indexed in uppercase in 1.4 but lowercase in 1.5... i hope this makes sense.
        Hide
        Mark Miller added a comment -

        Agreed - we don't want to cause those that don't need to to reindex just to try and be safe.

        Show
        Mark Miller added a comment - Agreed - we don't want to cause those that don't need to to reindex just to try and be safe.
        Hide
        Robert Muir added a comment -

        Hi Marvin, thanks for reviewing it.

        ... but I still think the message is a little too aggressive. There are a lot
        of people just using ye olde StandardAnalyzer, and they don't need to reindex.
        We don't need to spread our own FUD.

        are you sure? StandardAnalyzer uses LowerCaseFilter, i did not check to see if any casing properties have changed.

        Can we change it to say "Analyzers", and then refer people to the docs for
        their specific Analyzer? Alternatively, should that notification just contain
        a complete list of the affected classes?

        Basically I am trying to be ambiguous, because I'm not sure what all is affected without doing some significant analysis!
        I will do this, if its the right thing though.

        Show
        Robert Muir added a comment - Hi Marvin, thanks for reviewing it. ... but I still think the message is a little too aggressive. There are a lot of people just using ye olde StandardAnalyzer, and they don't need to reindex. We don't need to spread our own FUD. are you sure? StandardAnalyzer uses LowerCaseFilter, i did not check to see if any casing properties have changed. Can we change it to say "Analyzers", and then refer people to the docs for their specific Analyzer? Alternatively, should that notification just contain a complete list of the affected classes? Basically I am trying to be ambiguous, because I'm not sure what all is affected without doing some significant analysis! I will do this, if its the right thing though.
        Hide
        Marvin Humphrey added a comment -

        I like this:

        > some parts of Lucene

        ... but I still think the message is a little too aggressive. There are a lot
        of people just using ye olde StandardAnalyzer, and they don't need to reindex.
        We don't need to spread our own FUD.

        Can we change it to say "Analyzers", and then refer people to the docs for
        their specific Analyzer? Alternatively, should that notification just contain
        a complete list of the affected classes?

        Show
        Marvin Humphrey added a comment - I like this: > some parts of Lucene ... but I still think the message is a little too aggressive. There are a lot of people just using ye olde StandardAnalyzer, and they don't need to reindex. We don't need to spread our own FUD. Can we change it to say "Analyzers", and then refer people to the docs for their specific Analyzer? Alternatively, should that notification just contain a complete list of the affected classes?
        Hide
        Robert Muir added a comment -

        ok, i think this one is better.
        For convenience, I list which JRE versions correspond to which unicode versions.

        Because I think that for example, if someone goes from Java 5 to Java 6, they should not worry about this.

        Show
        Robert Muir added a comment - ok, i think this one is better. For convenience, I list which JRE versions correspond to which unicode versions. Because I think that for example, if someone goes from Java 5 to Java 6, they should not worry about this.
        Hide
        Robert Muir added a comment -

        i tried to improve the wording a bit.

        Show
        Robert Muir added a comment - i tried to improve the wording a bit.
        Hide
        Robert Muir added a comment -

        I guess that warning still isnt good enough. if you bump jvm version you should reindex older data too, and not just add new documents to it...

        Show
        Robert Muir added a comment - I guess that warning still isnt good enough. if you bump jvm version you should reindex older data too, and not just add new documents to it...
        Hide
        Robert Muir added a comment -

        Hello, whereever we put this text (i do not care), I thought the following would be a start.

        please help me make it easier to digest/understand

        If possible, use the same major JVM version at both index and search time.
        Different JVM versions may implement different versions of the Unicode Standard, which will change the way Lucene treats your text.
        For example, under Java 1.4, LetterTokenizer will split around the character U+02C6, but under Java 5 it will not.
        This is because Java 1.4 implements Unicode 3, but Java 5 implements Unicode 4.
        
        Show
        Robert Muir added a comment - Hello, whereever we put this text (i do not care), I thought the following would be a start. please help me make it easier to digest/understand If possible, use the same major JVM version at both index and search time. Different JVM versions may implement different versions of the Unicode Standard, which will change the way Lucene treats your text. For example, under Java 1.4, LetterTokenizer will split around the character U+02C6, but under Java 5 it will not. This is because Java 1.4 implements Unicode 3, but Java 5 implements Unicode 4.
        Hide
        Robert Muir added a comment -

        Which components are affected by this? I think just Analyzers and query parsers, yes?

        I think just tokenstreams / analyzers.

        This isn't a fundamental problem with the Lucene architecture; it's an artifact of the way certain classes are implemented.

        yes, you are exactly right. StandardTokenizer does not have this problem. its behavior is independent of the users JVM, although dependent on the JVM of the developer who last re-ran jflex

        Perhaps there could be an "ICUAnalysis" package which depends on ICU4J

        yeah, this is what I think most of us who need unicode support do anyway. so i tried to start a good impl of this in LUCENE-1488.
        even if you do not care about unicode support, maybe you care that things like .isWhiteSpace() are faster than in the jdk:
        http://site.icu-project.org/home/why-use-icu4j (see under Performance section).

        Show
        Robert Muir added a comment - Which components are affected by this? I think just Analyzers and query parsers, yes? I think just tokenstreams / analyzers. This isn't a fundamental problem with the Lucene architecture; it's an artifact of the way certain classes are implemented. yes, you are exactly right. StandardTokenizer does not have this problem. its behavior is independent of the users JVM, although dependent on the JVM of the developer who last re-ran jflex Perhaps there could be an "ICUAnalysis" package which depends on ICU4J yeah, this is what I think most of us who need unicode support do anyway. so i tried to start a good impl of this in LUCENE-1488 . even if you do not care about unicode support, maybe you care that things like .isWhiteSpace() are faster than in the jdk: http://site.icu-project.org/home/why-use-icu4j (see under Performance section).
        Hide
        Mark Miller added a comment -

        If that's true, my inclination would be to add a note to the javadocs for each
        such class. In every case, it's theoretically possible to build alternative
        implementations which are unaffected by upgrading the JVM.

        I think thats a good idea, but I'd still like the top level warning as well - I think it should be specific in explaining the problem, and not claim that it exists for everything - Robert has already laid out a couple specific examples we can mention. The problem with the javadoc approach only is that its very easy to miss - I think its a good place to lay out the details for that particular class - but it would still be great to have a visible top level warning so that users know to be careful of this.

        Show
        Mark Miller added a comment - If that's true, my inclination would be to add a note to the javadocs for each such class. In every case, it's theoretically possible to build alternative implementations which are unaffected by upgrading the JVM. I think thats a good idea, but I'd still like the top level warning as well - I think it should be specific in explaining the problem, and not claim that it exists for everything - Robert has already laid out a couple specific examples we can mention. The problem with the javadoc approach only is that its very easy to miss - I think its a good place to lay out the details for that particular class - but it would still be great to have a visible top level warning so that users know to be careful of this.
        Hide
        Marvin Humphrey added a comment -

        Which components are affected by this? I think just Analyzers and query
        parsers, yes?

        If that's true, my inclination would be to add a note to the javadocs for each
        such class. In every case, it's theoretically possible to build alternative
        implementations which are unaffected by upgrading the JVM.

        This isn't a fundamental problem with the Lucene architecture; it's an
        artifact of the way certain classes are implemented. Outside of the affected
        components, Lucene doesn't get down and dirty with Unicode properties and
        other fast-moving stuff – it's just dealing in UTF-8 bytes, Java strings,
        etc. Those things can change (Modified UTF-8, shudder), but they move on a
        slower timescale.

        Arguably, Analyzer subclasses shouldn't be in core for reasons like this.
        Perhaps there could be an "ICUAnalysis" package which depends on ICU4J, so
        that Unicode-related index incompatibilites occur when you upgrade your
        Unicode library. Though most people would probably choose to use the
        smaller-footprint, zero-dependency "JVMAnalysis" package, where reindexing
        would be required after a JVM upgrade.

        The software certifiers wouldn't like that, and I'm not seriously advocating
        such a disruptive change (yet), but I just wanted to illustrate that this is a
        contained problem.

        Show
        Marvin Humphrey added a comment - Which components are affected by this? I think just Analyzers and query parsers, yes? If that's true, my inclination would be to add a note to the javadocs for each such class. In every case, it's theoretically possible to build alternative implementations which are unaffected by upgrading the JVM. This isn't a fundamental problem with the Lucene architecture; it's an artifact of the way certain classes are implemented. Outside of the affected components, Lucene doesn't get down and dirty with Unicode properties and other fast-moving stuff – it's just dealing in UTF-8 bytes, Java strings, etc. Those things can change (Modified UTF-8, shudder), but they move on a slower timescale. Arguably, Analyzer subclasses shouldn't be in core for reasons like this. Perhaps there could be an "ICUAnalysis" package which depends on ICU4J, so that Unicode-related index incompatibilites occur when you upgrade your Unicode library. Though most people would probably choose to use the smaller-footprint, zero-dependency "JVMAnalysis" package, where reindexing would be required after a JVM upgrade. The software certifiers wouldn't like that, and I'm not seriously advocating such a disruptive change (yet), but I just wanted to illustrate that this is a contained problem.
        Hide
        Mark Miller added a comment -

        Sounds good to me.

        Show
        Mark Miller added a comment - Sounds good to me.
        Hide
        Uwe Schindler added a comment -

        How about adding a general note into some JRE_VERSION_MIGRATION.txt on each release, also add this to the non-version specific site docs?
        The first version that would contain it in the distribution would be 3.0, but it should be noted on the site-docs, that this affects all versions. Something like "whenever you change JRE major versions 1.4 -> 1.5 -> 1.6 -> 1.7 you may have to reindex, because the underlying VM's Unicode version could have changed in a way, affecting your tokenizers."

        Show
        Uwe Schindler added a comment - How about adding a general note into some JRE_VERSION_MIGRATION.txt on each release, also add this to the non-version specific site docs? The first version that would contain it in the distribution would be 3.0, but it should be noted on the site-docs, that this affects all versions. Something like "whenever you change JRE major versions 1.4 -> 1.5 -> 1.6 -> 1.7 you may have to reindex, because the underlying VM's Unicode version could have changed in a way, affecting your tokenizers."
        Hide
        Robert Muir added a comment -

        Mark, I agree, there are two issues I know of:

        • using a new java version can change unicode version, which changes character properties, which makes things tokenize differently.
        • using a different default locale can change at least some things in contrib, for example PatternAnalyzer uses a Locale-based toLowerCase() method, which will break if default locale is different between index and search.

        ... <other things you can think of>

        Show
        Robert Muir added a comment - Mark, I agree, there are two issues I know of: using a new java version can change unicode version, which changes character properties, which makes things tokenize differently. using a different default locale can change at least some things in contrib, for example PatternAnalyzer uses a Locale-based toLowerCase() method, which will break if default locale is different between index and search. ... <other things you can think of>

          People

          • Assignee:
            Robert Muir
            Reporter:
            Mark Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development