Solr
  1. Solr
  2. SOLR-5594

Enable using extended field types with prefix queries for non-default encoded strings

    Details

      Description

      Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings.

      Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better.

      1. SOLR-5594.patch
        26 kB
        Anshum Gupta
      2. SOLR-5594.patch
        26 kB
        Anshum Gupta
      3. SOLR-5594.patch
        23 kB
        Anshum Gupta
      4. SOLR-5594.patch
        30 kB
        Anshum Gupta
      5. SOLR-5594.patch
        15 kB
        Anshum Gupta
      6. SOLR-5594.patch
        3 kB
        Anshum Gupta
      7. SOLR-5594-branch_4x.patch
        16 kB
        Anshum Gupta

        Activity

        Hide
        Yonik Seeley added a comment - - edited

        readableToIndexed may not work well with some types... perhaps we should have a
        FieldType.getPrefixQuery(QParser qparser, SchemaField sfield, String prefix)
        essentially do it like getRangeQuery

        Show
        Yonik Seeley added a comment - - edited readableToIndexed may not work well with some types... perhaps we should have a FieldType.getPrefixQuery(QParser qparser, SchemaField sfield, String prefix) essentially do it like getRangeQuery
        Hide
        Anshum Gupta added a comment -

        Thanks for the suggestion Yonik. Coming to think about it, that absolutely makes more sense.

        Show
        Anshum Gupta added a comment - Thanks for the suggestion Yonik. Coming to think about it, that absolutely makes more sense.
        Hide
        Anshum Gupta added a comment -

        Sans the test. Working on the tests right now.

        Show
        Anshum Gupta added a comment - Sans the test. Working on the tests right now.
        Hide
        Anshum Gupta added a comment -

        Patch for 4x with test.
        There one thing I'd like to do better though. To avoid a dependency on lucene tests, I added BinaryTokenStream.java to solr-core-test.
        I'll try and get rid of it but it'd be good to have feedback in the meanwhile.

        Also, I'll add a test that works with trunk (which might require a bit of rework).

        Show
        Anshum Gupta added a comment - Patch for 4x with test. There one thing I'd like to do better though. To avoid a dependency on lucene tests, I added BinaryTokenStream.java to solr-core-test. I'll try and get rid of it but it'd be good to have feedback in the meanwhile. Also, I'll add a test that works with trunk (which might require a bit of rework).
        Hide
        Hoss Man added a comment -
        • Aren't there other parsers classes that will need similar changes? (PrefixQParserPlugin, SimplerQParserPlugin at a minimum i think)
        • I think your new FieldType.getPrefixQuery method has a back compat break for any existing FieldTypes that people might be using because it now calls readableToIndexed ... that smells like it could break things for some FieldTypes ... but maybe i'm missing something?
        • FieldType.getPrefixQuery has lots of bogus cut/pasted javadocs from getRangeQuery
        • Can't your MyIndexedBinaryField just subclass BinaryField to reduce some code? for that matter: is there any reason why we shouldn't just make BinaryField implement prefix queries in the way your MyIndexedBinaryField does?
        • i'm not sure i understand why you need BinaryTokenStream for the test (see previous comment about just extending/improving BinaryField) but if so perhaps it should be moved from lucene/core to lucene/test-framework?
        Show
        Hoss Man added a comment - Aren't there other parsers classes that will need similar changes? (PrefixQParserPlugin, SimplerQParserPlugin at a minimum i think) I think your new FieldType.getPrefixQuery method has a back compat break for any existing FieldTypes that people might be using because it now calls readableToIndexed ... that smells like it could break things for some FieldTypes ... but maybe i'm missing something? FieldType.getPrefixQuery has lots of bogus cut/pasted javadocs from getRangeQuery Can't your MyIndexedBinaryField just subclass BinaryField to reduce some code? for that matter: is there any reason why we shouldn't just make BinaryField implement prefix queries in the way your MyIndexedBinaryField does? i'm not sure i understand why you need BinaryTokenStream for the test (see previous comment about just extending/improving BinaryField) but if so perhaps it should be moved from lucene/core to lucene/test-framework?
        Hide
        Anshum Gupta added a comment -

        Here's another patch.

        Show
        Anshum Gupta added a comment - Here's another patch.
        Hide
        Anshum Gupta added a comment -

        Thanks for the feedback Hoss!

        I've tried to be less invasive this time around and have avoided using readableToIndexed in the base class. I've also fixed the javadocs.
        About using the BinaryTokenStream (extending BinaryField), I may be missing something as far as the reason is concerned but it's tough to work with BinaryFields right now. They can not be indexed really and the only way to index a binary field is through the hack I put it.
        I've removed all of that and made this more generic.

        I'll also open a separate JIRA to make BinaryFields better and more usable.

        Here's what still remains before this can be checked in:

        • Fix/change dependent Parser classes e.g. PrefixQParserPlugin and SimpleQParserPlugin.
        • A test that shows that things haven't changed for the existing field types as far as Prefix Queries are concerned.

        Need a couple of hours for that.

        Show
        Anshum Gupta added a comment - Thanks for the feedback Hoss! I've tried to be less invasive this time around and have avoided using readableToIndexed in the base class. I've also fixed the javadocs. About using the BinaryTokenStream (extending BinaryField), I may be missing something as far as the reason is concerned but it's tough to work with BinaryFields right now. They can not be indexed really and the only way to index a binary field is through the hack I put it. I've removed all of that and made this more generic. I'll also open a separate JIRA to make BinaryFields better and more usable. Here's what still remains before this can be checked in: Fix/change dependent Parser classes e.g. PrefixQParserPlugin and SimpleQParserPlugin. A test that shows that things haven't changed for the existing field types as far as Prefix Queries are concerned. Need a couple of hours for that.
        Show
        Anshum Gupta added a comment - https://issues.apache.org/jira/browse/SOLR-5619
        Hide
        Anshum Gupta added a comment -

        Patch with the following changes:

        • Fixes to SimpleQParserPlugin and PrefixQParserPlugin
        • Test to show that prefix query for integer fields works as it did prior to this change.
        • Test to show how custom fields override getPrefixQuery() method for 2 different custom fields.
        Show
        Anshum Gupta added a comment - Patch with the following changes: Fixes to SimpleQParserPlugin and PrefixQParserPlugin Test to show that prefix query for integer fields works as it did prior to this change. Test to show how custom fields override getPrefixQuery() method for 2 different custom fields.
        Hide
        Anshum Gupta added a comment -

        There was something wrong with the last patch. Here's another one.

        Show
        Anshum Gupta added a comment - There was something wrong with the last patch. Here's another one.
        Hide
        Robert Muir added a comment -

        Can we avoid reformatting SimpleQParser here? it makes it impossible to review the changes

        Show
        Robert Muir added a comment - Can we avoid reformatting SimpleQParser here? it makes it impossible to review the changes
        Hide
        Anshum Gupta added a comment -

        Robert, I thought about how to handle SimleQParser with this change before I even put up this patch but I can't think of another way to handle it here. This seems like the best way to go as far as handling SimpleQParser for this change is concerned.

        Show
        Anshum Gupta added a comment - Robert, I thought about how to handle SimleQParser with this change before I even put up this patch but I can't think of another way to handle it here. This seems like the best way to go as far as handling SimpleQParser for this change is concerned.
        Hide
        Robert Muir added a comment -

        Thats not what i mean: i mean that in the patch its not possible to see your actual logic changes, because every single line of code is reformatted.

        Show
        Robert Muir added a comment - Thats not what i mean: i mean that in the patch its not possible to see your actual logic changes, because every single line of code is reformatted.
        Hide
        Anshum Gupta added a comment -

        I'm sorry I misread it. Perhaps it's something that idea did. Let me have a look at it and fix that.
        Thanks for pointing that out.

        Show
        Anshum Gupta added a comment - I'm sorry I misread it. Perhaps it's something that idea did. Let me have a look at it and fix that. Thanks for pointing that out.
        Hide
        Anshum Gupta added a comment -

        Fixed the reformatting, however as things have moved (and there's been a level change.. new inner classes etc) it still looks a little tricky but yes, it's no longer just reformatted code in the patch.

        Show
        Anshum Gupta added a comment - Fixed the reformatting, however as things have moved (and there's been a level change.. new inner classes etc) it still looks a little tricky but yes, it's no longer just reformatted code in the patch.
        Hide
        Hoss Man added a comment -

        Anshum: looks pretty good ... a few requests...

        • SolrQueryParserBase.newPrefixQuery shouldnt' be removed completely (it's protected, subclasses might be using it) ... just update it to call the new method on the FieldType.
        • can you add some javadocs to the test classes (particularly the new field types) with an explanation of what they do and why they are special
        • can we change the field names in your test schema (currently "customfield" and "customfield2") to something more clear what they do (ie: "swap_foo_bar" and "int_prefix_as_range") so the (expected) wonky behavior is less confusing when reading the test?
        • the tests should be updated to show that using {!prefix} and {!simple} also works with your custom field types
        • ideally we want to show that {!prefix}, {!simple}, and {!lucene} all produce queries that are equals() when using your custom field types (take a look at QueryEqualityTest for inspiration)
        Show
        Hoss Man added a comment - Anshum: looks pretty good ... a few requests... SolrQueryParserBase.newPrefixQuery shouldnt' be removed completely (it's protected, subclasses might be using it) ... just update it to call the new method on the FieldType. can you add some javadocs to the test classes (particularly the new field types) with an explanation of what they do and why they are special can we change the field names in your test schema (currently "customfield" and "customfield2") to something more clear what they do (ie: "swap_foo_bar" and "int_prefix_as_range") so the (expected) wonky behavior is less confusing when reading the test? the tests should be updated to show that using { !prefix } and { !simple } also works with your custom field types ideally we want to show that { !prefix }, { !simple }, and { !lucene } all produce queries that are equals() when using your custom field types (take a look at QueryEqualityTest for inspiration)
        Hide
        Ryan Ernst added a comment -

        Fixed the reformatting, however as things have moved (and there's been a level change.. new inner classes etc) it still looks a little tricky but yes, it's no longer just reformatted code in the patch.

        Why are any of the changes in SimpleQParser necessary, except for changing new PrefixQuery(...) to sf.getType().getPrefixQuery()? It looks like all the other changes there are unnecessary structural changes. Since the IndexSchema is already available, it should be just a couple lines changed (180/183).

        Why not just make the necessary changes for this issue, and open another jira if you feel static inner classes would be better here (although I don't see why two are necessary)?

        Show
        Ryan Ernst added a comment - Fixed the reformatting, however as things have moved (and there's been a level change.. new inner classes etc) it still looks a little tricky but yes, it's no longer just reformatted code in the patch. Why are any of the changes in SimpleQParser necessary, except for changing new PrefixQuery(...) to sf.getType().getPrefixQuery() ? It looks like all the other changes there are unnecessary structural changes. Since the IndexSchema is already available, it should be just a couple lines changed (180/183). Why not just make the necessary changes for this issue, and open another jira if you feel static inner classes would be better here (although I don't see why two are necessary)?
        Hide
        Uwe Schindler added a comment -

        SolrQueryParserBase.newPrefixQuery shouldnt' be removed completely (it's protected, subclasses might be using it) ... just update it to call the new method on the FieldType.

        Why are any of the changes in SimpleQParser necessary, except for changing new PrefixQuery(...) to sf.getType().getPrefixQuery()? It looks like all the other changes there are unnecessary structural changes. Since the IndexSchema is already available, it should be just a couple lines changed (180/183).

        Yes, this would also be identical to range query behaviour: newRangeQuery also delegates to the field type, and the protected method is there for subclasses.

        Show
        Uwe Schindler added a comment - SolrQueryParserBase.newPrefixQuery shouldnt' be removed completely (it's protected, subclasses might be using it) ... just update it to call the new method on the FieldType. Why are any of the changes in SimpleQParser necessary, except for changing new PrefixQuery(...) to sf.getType().getPrefixQuery()? It looks like all the other changes there are unnecessary structural changes. Since the IndexSchema is already available, it should be just a couple lines changed (180/183). Yes, this would also be identical to range query behaviour: newRangeQuery also delegates to the field type, and the protected method is there for subclasses.
        Hide
        Anshum Gupta added a comment -

        Thanks for having a look at it. I'm traveling until Monday (= without reliable internet connection) so would have a look at it again once I get back home and add comments/changes then.

        Show
        Anshum Gupta added a comment - Thanks for having a look at it. I'm traveling until Monday (= without reliable internet connection) so would have a look at it again once I get back home and add comments/changes then.
        Hide
        Hoss Man added a comment -

        Why are any of the changes in SimpleQParser necessary, except for changing new PrefixQuery(...) to sf.getType().getPrefixQuery()? It looks like all the other changes there are unnecessary structural changes. Since the IndexSchema is already available, it should be just a couple lines changed (180/183).

        This confused me too ... but the structural changes are necessary in order to pass the QParser down to the FieldType's method for the context of what is being parsed – with both the QParser and the SimpleQueryParser instances being anonymous subclasses, it's not possible at the moment.

        (I don't remember if the QParser context is used at the moment in any of the new FieldType.newPrefixQuery impls, but that either way that param should exist in case FieldType subclasses want to take advantage of it)

        Show
        Hoss Man added a comment - Why are any of the changes in SimpleQParser necessary, except for changing new PrefixQuery(...) to sf.getType().getPrefixQuery()? It looks like all the other changes there are unnecessary structural changes. Since the IndexSchema is already available, it should be just a couple lines changed (180/183). This confused me too ... but the structural changes are necessary in order to pass the QParser down to the FieldType's method for the context of what is being parsed – with both the QParser and the SimpleQueryParser instances being anonymous subclasses, it's not possible at the moment. (I don't remember if the QParser context is used at the moment in any of the new FieldType.newPrefixQuery impls, but that either way that param should exist in case FieldType subclasses want to take advantage of it)
        Hide
        Anshum Gupta added a comment - - edited

        Hoss: Thanks for taking that up before I got back.

        Yes, this would also be identical to range query behaviour: newRangeQuery also delegates to the field type, and the protected method is there for subclasses.

        My changes are Solr specific. I'm not sure how would it play with the Solr QParsers (Solr extended fields) if I moved the changes to Lucene instead of Solr.

        Show
        Anshum Gupta added a comment - - edited Hoss: Thanks for taking that up before I got back. Yes, this would also be identical to range query behaviour: newRangeQuery also delegates to the field type, and the protected method is there for subclasses. My changes are Solr specific. I'm not sure how would it play with the Solr QParsers (Solr extended fields) if I moved the changes to Lucene instead of Solr.
        Hide
        Anshum Gupta added a comment -

        Chris Hostetter (Unused) : I'll make the recommended changes and put up another patch.

        Show
        Anshum Gupta added a comment - Chris Hostetter (Unused) : I'll make the recommended changes and put up another patch.
        Hide
        Anshum Gupta added a comment - - edited

        Patch with the following changes:

        • Added back SolrQueryParserBase.newPrefixQuery so that it doesn't break backward compatibility.
        • Added some javadocs to the test classes
        • Changed the names of custom fields in the new test schema.
        • Added tests that show {!prefix}, {!simple}, and {!lucene} all produce queries that are .equals() for custom field.
        Show
        Anshum Gupta added a comment - - edited Patch with the following changes: Added back SolrQueryParserBase.newPrefixQuery so that it doesn't break backward compatibility. Added some javadocs to the test classes Changed the names of custom fields in the new test schema. Added tests that show { !prefix }, { !simple }, and { !lucene } all produce queries that are .equals() for custom field.
        Hide
        Hoss Man added a comment -

        Anshum: this all looks great, except for 3 things...

        • my point about testing that the querys produced by all the parsers are .equals() was about the queries produced by each parser being equal to each other. The point is regardless of which parser you use, the resulting queries should be the same because we now delegate to the FieldType. So instead of distinct testQuerySimple, testQueryLucene, testQueryPrefix methods each using a single parser, we should have a test that shows something like this...
          assertQueryEquals(req,
            "{!lucene df=swap_foo_bar_in_prefix_query}foo*",
            "{!simple f=swap_foo_bar_in_prefix_query}foo*",
            "{!prefix f=swap_foo_bar_in_prefix_query}foo",
            ...);
          assertQueryEquals(req,
            "{!lucene}int_prefix_as_range:[42 TO *]",
            "{!lucene}int_prefix_as_range:42*",
            "{!simple}int_prefix_as_range:[42 TO *]",
            "{!simple}int_prefix_as_range:42*",
            "{!prefix f=int_prefix_as_range}42",
            ...);
          

          ...you see what i mean?

        • new Random() is not allowed - you need to use random() inherited from the test baseclass. you can use "ant precommit" to help spot mistakes like this.
        • taking a second look at your assertions about swap_foo_bar_in_prefix_query, i don't actually think they are very strong, since (unless i'm missing something?) the number of docs containing "foo" prefixes and the number of docs containing "bar" prefixes will be the same. you should change the math so that one is less common then the other, and mix in some values that don't match either prefix as well. (ie: let the field be multivalued, and if the id is a multiple of 3, add a foo term, if it's a multiple of 7 add a bar term, and if it's a multiple of 11 add a zzz term - then assert the expected counts based on the total number of docs)
        Show
        Hoss Man added a comment - Anshum: this all looks great, except for 3 things... my point about testing that the querys produced by all the parsers are .equals() was about the queries produced by each parser being equal to each other . The point is regardless of which parser you use, the resulting queries should be the same because we now delegate to the FieldType. So instead of distinct testQuerySimple, testQueryLucene, testQueryPrefix methods each using a single parser, we should have a test that shows something like this... assertQueryEquals(req, "{!lucene df=swap_foo_bar_in_prefix_query}foo*" , "{!simple f=swap_foo_bar_in_prefix_query}foo*" , "{!prefix f=swap_foo_bar_in_prefix_query}foo" , ...); assertQueryEquals(req, "{!lucene}int_prefix_as_range:[42 TO *]" , "{!lucene}int_prefix_as_range:42*" , "{!simple}int_prefix_as_range:[42 TO *]" , "{!simple}int_prefix_as_range:42*" , "{!prefix f=int_prefix_as_range}42" , ...); ...you see what i mean? new Random() is not allowed - you need to use random() inherited from the test baseclass. you can use "ant precommit" to help spot mistakes like this. taking a second look at your assertions about swap_foo_bar_in_prefix_query, i don't actually think they are very strong, since (unless i'm missing something?) the number of docs containing "foo" prefixes and the number of docs containing "bar" prefixes will be the same. you should change the math so that one is less common then the other, and mix in some values that don't match either prefix as well. (ie: let the field be multivalued, and if the id is a multiple of 3, add a foo term, if it's a multiple of 7 add a bar term, and if it's a multiple of 11 add a zzz term - then assert the expected counts based on the total number of docs)
        Hide
        Anshum Gupta added a comment -

        Thanks for the patience Hoss.

        • I get what you're trying to put forward about asserting the queries to be equal. I've made those changes and I'm trying to get the test to pass for now (which isn't happening for now).
        • The numDocs for each of those would be different, but yes, by adding what you suggested it would only become stronger. I'll add that too.

        When I run "ant precommit", I just get "The following files are missing svn:eol-style" (perhaps it stops right there) followed by a list of files.

        Show
        Anshum Gupta added a comment - Thanks for the patience Hoss. I get what you're trying to put forward about asserting the queries to be equal. I've made those changes and I'm trying to get the test to pass for now (which isn't happening for now). The numDocs for each of those would be different, but yes, by adding what you suggested it would only become stronger. I'll add that too. When I run "ant precommit", I just get "The following files are missing svn:eol-style" (perhaps it stops right there) followed by a list of files.
        Hide
        Anshum Gupta added a comment -

        I’ve tried Mac EOL styles(\r) , *nix style EOL (\n) and OS dependent (which should also be mac style) but in vain.

        Show
        Anshum Gupta added a comment - I’ve tried Mac EOL styles(\r) , *nix style EOL (\n) and OS dependent (which should also be mac style) but in vain.
        Hide
        Anshum Gupta added a comment -
        • randomized the doc counts more (more like a 2:1 distribution).
        • Checked for query equality across qparsers.

        I haven't been able to run ant precommit yet so have just fixed "new Random()" for now.
        Once I figure out (or know) how to fix the EOL issue, I'll run ant precommit to fix any further issues on that front.

        Show
        Anshum Gupta added a comment - randomized the doc counts more (more like a 2:1 distribution). Checked for query equality across qparsers. I haven't been able to run ant precommit yet so have just fixed "new Random()" for now. Once I figure out (or know) how to fix the EOL issue, I'll run ant precommit to fix any further issues on that front.
        Hide
        Anshum Gupta added a comment -

        Figured that out and ran it, only to run into the same issue twice over:
        lucene-trunk2/lucene/common-build.xml:1851: java.lang.OutOfMemoryError: Java heap space

        is this a known issue or am I missing something here?

        Show
        Anshum Gupta added a comment - Figured that out and ran it, only to run into the same issue twice over: lucene-trunk2/lucene/common-build.xml:1851: java.lang.OutOfMemoryError: Java heap space is this a known issue or am I missing something here?
        Hide
        Anshum Gupta added a comment -

        Ran "ant check-forbidden-apis" successfully.

        Show
        Anshum Gupta added a comment - Ran "ant check-forbidden-apis" successfully.
        Hide
        Steve Rowe added a comment -

        Once I figure out (or know) how to fix the EOL issue, I'll run ant precommit to fix any further issues on that front.

        In case you haven't figured it out yet, you just run svn propset svn:eol-style native <file(s)>, where <file(s)> is the (list of) file(s) that don't have the svn:eol-style property set on them. This info should be on Lucene's and Solr's HowToContribute wiki pages, though I see it's not there yet.

        Figured that out and ran it, only to run into the same issue twice over:
        lucene-trunk2/lucene/common-build.xml:1851: java.lang.OutOfMemoryError: Java heap space

        Line 1851 in lucene/common-build.xml runs the JTidy Ant task. According to the comment on line 341:

              <!-- TODO: Fix this! For now only run this on 64bit, because jTIDY OOMs with default heap size: -->
        

        You can give arguments to the JVM that runs ant via the environment variable ANT_OPTS. Here's mine (on Win7+Cygwin under bash):

        export ANT_OPTS=-Xmx1100M -XX:MaxPermSize=256m -Dpython.exe=python2.6.exe -Dpython32.exe=python3.2m.exe
        

        I doubt the JTidy Ant task requires 1100MB, but the JFlex Ant task OOMs with anything less than 1040MB on my box when it generates UAX29URLEmailTokenizerImpl.java (via ant jflex under lucene/analysis/common/, so that's why I have it set that high.

        Show
        Steve Rowe added a comment - Once I figure out (or know) how to fix the EOL issue, I'll run ant precommit to fix any further issues on that front. In case you haven't figured it out yet, you just run svn propset svn:eol-style native <file(s)> , where <file(s)> is the (list of) file(s) that don't have the svn:eol-style property set on them. This info should be on Lucene's and Solr's HowToContribute wiki pages, though I see it's not there yet. Figured that out and ran it, only to run into the same issue twice over: lucene-trunk2/lucene/common-build.xml:1851: java.lang.OutOfMemoryError: Java heap space Line 1851 in lucene/common-build.xml runs the JTidy Ant task. According to the comment on line 341: <!-- TODO: Fix this! For now only run this on 64bit, because jTIDY OOMs with default heap size: --> You can give arguments to the JVM that runs ant via the environment variable ANT_OPTS . Here's mine (on Win7+Cygwin under bash): export ANT_OPTS=-Xmx1100M -XX:MaxPermSize=256m -Dpython.exe=python2.6.exe -Dpython32.exe=python3.2m.exe I doubt the JTidy Ant task requires 1100MB, but the JFlex Ant task OOMs with anything less than 1040MB on my box when it generates UAX29URLEmailTokenizerImpl.java (via ant jflex under lucene/analysis/common/ , so that's why I have it set that high.
        Hide
        Anshum Gupta added a comment -

        Thanks for that info Steve. I was able to set the svn property (just that I was trying to accomplish that through my IDE, which didn't work).
        Also, I'll use those ANT_OPTS to have stuff working for now.

        Show
        Anshum Gupta added a comment - Thanks for that info Steve. I was able to set the svn property (just that I was trying to accomplish that through my IDE, which didn't work). Also, I'll use those ANT_OPTS to have stuff working for now.
        Hide
        ASF subversion and git services added a comment -

        Commit 1560412 from hossman@apache.org in branch 'dev/trunk'
        [ https://svn.apache.org/r1560412 ]

        SOLR-5594: Allow FieldTypes to specify custom PrefixQuery behavior

        Show
        ASF subversion and git services added a comment - Commit 1560412 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1560412 ] SOLR-5594 : Allow FieldTypes to specify custom PrefixQuery behavior
        Hide
        ASF subversion and git services added a comment -

        Commit 1560432 from hossman@apache.org in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1560432 ]

        SOLR-5594: Allow FieldTypes to specify custom PrefixQuery behavior (merge r1560412)

        Show
        ASF subversion and git services added a comment - Commit 1560432 from hossman@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1560432 ] SOLR-5594 : Allow FieldTypes to specify custom PrefixQuery behavior (merge r1560412)
        Hide
        Hoss Man added a comment -

        Thanks Anshum!

        Committed revision 1560412.
        Committed revision 1560432.

        Show
        Hoss Man added a comment - Thanks Anshum! Committed revision 1560412. Committed revision 1560432.

          People

          • Assignee:
            Anshum Gupta
            Reporter:
            Anshum Gupta
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development