Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Sometimes queries executed via the MemoryIndex require certain things to be stored as doc values. Today this isn't possible because the memory index doesn't support this and these queries silently return no results.

      1. LUCENE-7091.patch
        40 kB
        Martijn van Groningen
      2. LUCENE-7091.patch
        40 kB
        Martijn van Groningen
      3. LUCENE-7091.patch
        39 kB
        Martijn van Groningen
      4. LUCENE-7091.patch
        37 kB
        Martijn van Groningen
      5. LUCENE-7091.patch
        37 kB
        Martijn van Groningen
      6. LUCENE-7091.patch
        37 kB
        Martijn van Groningen
      7. LUCENE-7091.patch
        35 kB
        Martijn van Groningen
      8. LUCENE-7091.patch
        32 kB
        Martijn van Groningen
      9. LUCENE-7091.patch
        28 kB
        Martijn van Groningen

        Activity

        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Added a test that adds simple doc values support for doc values. Nothing fancy here, but should just work.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Added a test that adds simple doc values support for doc values. Nothing fancy here, but should just work.
        Hide
        romseygeek Alan Woodward added a comment -

        +1, nice!

        Is there any reason for DocValuesHolder to be package-private?

        Show
        romseygeek Alan Woodward added a comment - +1, nice! Is there any reason for DocValuesHolder to be package-private?
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Is there any reason for DocValuesHolder to be package-private?

        No, nothing outside MemoryIndex uses it. I can change the visibility to private.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Is there any reason for DocValuesHolder to be package-private? No, nothing outside MemoryIndex uses it. I can change the visibility to private.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment - - edited

        Updated the patch:

        • Made sure the sorted set doc values doesn't have duplicate values.
        • Added extra test to verify that unsupported usage fails.
        • Changed DocValuesHolder class' visibility to private .
        Show
        martijn.v.groningen Martijn van Groningen added a comment - - edited Updated the patch: Made sure the sorted set doc values doesn't have duplicate values. Added extra test to verify that unsupported usage fails. Changed DocValuesHolder class' visibility to private .
        Hide
        dsmiley David Smiley added a comment -

        Cool.

        Instead of DocValuesHolder, how about actually having one implementation class per DocValues type that holds the value. So, a MemoryNumericDocValues for example. In your patch you do an anonymous class for each one but I think it would be clearer to not do that and eliminate the DocValuesHolder which is holding for multiple types of values at once which is a little confusing. Note SortedDocValues extends BinaryDocValues so that eliminates an implementation. I wish Lucene's DocValue abstractions were interfaces and not abstract classes since it prevents collapsing some other similar implementations into fewer concrete classes.

        Could you move fields() above MemoryFields so it reads more naturally?

        Why is there a different sorting approach to sorted numeric vs BytesRef DV types? The former you add to an array and sort eventually, and the latter you use a TreeSet. They could both be handled consistently – array first then sort later.

        I noticed the BytesRefs DV data isn't copied; we retain a reference. Is that allowed? I suspect not; seems very risky. Notice that the term index data uses BytesRefHash wrapped around the shared ByteBlockPool. Perhaps we should do similarly using the same ByteBlockPool.

        Show
        dsmiley David Smiley added a comment - Cool. Instead of DocValuesHolder, how about actually having one implementation class per DocValues type that holds the value. So, a MemoryNumericDocValues for example. In your patch you do an anonymous class for each one but I think it would be clearer to not do that and eliminate the DocValuesHolder which is holding for multiple types of values at once which is a little confusing. Note SortedDocValues extends BinaryDocValues so that eliminates an implementation. I wish Lucene's DocValue abstractions were interfaces and not abstract classes since it prevents collapsing some other similar implementations into fewer concrete classes. Could you move fields() above MemoryFields so it reads more naturally? Why is there a different sorting approach to sorted numeric vs BytesRef DV types? The former you add to an array and sort eventually, and the latter you use a TreeSet. They could both be handled consistently – array first then sort later. I noticed the BytesRefs DV data isn't copied; we retain a reference. Is that allowed? I suspect not; seems very risky. Notice that the term index data uses BytesRefHash wrapped around the shared ByteBlockPool. Perhaps we should do similarly using the same ByteBlockPool.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Thanks for looking at this! I'll try to split this DocValuesHolder class into separate classes per DV type.

        In your patch you do an anonymous class for each one but I think it would be clearer to not do that and eliminate the DocValuesHolder which is holding for multiple types of values at once which is a little confusing.

        MemoryIndex is supposed to be thread safe after the freeze() method has been invoked. (this is describe in the jdocs) Returning the same doc values instance for binary, sorted, number and sorted number doc values is fine, but not for sorted set doc values. That implementation keeps state in order to iterate over the values. So for sorted set doc values we always need to return a new instance and in order to be consistent with the other doc values types I did they same thing there too. I think this isn't a big of deal.

        Could you move fields() above MemoryFields so it reads more naturally?

        Sure, will do

        Why is there a different sorting approach to sorted numeric vs BytesRef DV types? The former you add to an array and sort eventually, and the latter you use a TreeSet. They could both be handled consistently – array first then sort later.

        That is what I thought initially too, but the difference between the two is that sorted numeric DV can hold duplicates while sort set DV doesn't hold duplicates. This is why I took the approach of using treeset during the building phase for any binary DV.

        I noticed the BytesRefs DV data isn't copied; we retain a reference. Is that allowed?

        Good point, let me fix this.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Thanks for looking at this! I'll try to split this DocValuesHolder class into separate classes per DV type. In your patch you do an anonymous class for each one but I think it would be clearer to not do that and eliminate the DocValuesHolder which is holding for multiple types of values at once which is a little confusing. MemoryIndex is supposed to be thread safe after the freeze() method has been invoked. (this is describe in the jdocs) Returning the same doc values instance for binary, sorted, number and sorted number doc values is fine, but not for sorted set doc values. That implementation keeps state in order to iterate over the values. So for sorted set doc values we always need to return a new instance and in order to be consistent with the other doc values types I did they same thing there too. I think this isn't a big of deal. Could you move fields() above MemoryFields so it reads more naturally? Sure, will do Why is there a different sorting approach to sorted numeric vs BytesRef DV types? The former you add to an array and sort eventually, and the latter you use a TreeSet. They could both be handled consistently – array first then sort later. That is what I thought initially too, but the difference between the two is that sorted numeric DV can hold duplicates while sort set DV doesn't hold duplicates. This is why I took the approach of using treeset during the building phase for any binary DV. I noticed the BytesRefs DV data isn't copied; we retain a reference. Is that allowed? Good point, let me fix this.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        I've updated the patch based on David's comments.

        I did not split `DocValuesHolder` up in a class per DV type, but instead I've split it up in a class for the binary based DV and a class for the numeric based DV. So that the actual storage (long[] and BytesRefHash) is shared amongst the different DV impls. For all DV type but sorted set DV the patch now returns a pre set DV class.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - I've updated the patch based on David's comments. I did not split `DocValuesHolder` up in a class per DV type, but instead I've split it up in a class for the binary based DV and a class for the numeric based DV. So that the actual storage (long[] and BytesRefHash) is shared amongst the different DV impls. For all DV type but sorted set DV the patch now returns a pre set DV class.
        Hide
        dsmiley David Smiley added a comment -

        Returning the same doc values instance for binary, sorted, number and sorted number doc values is fine, but not for sorted set doc values.

        Good point.

        Some comments:

        • addField: unfortunately this method is very long and it's difficult to follow. I understand that it's not easy to split it up because of the number of local variables. One thing that would help is renaming "longValues" and "bytesValuesSet" to make them clearly associated with doc-values. I suggest "dvLongValues" and "dvBytesValuesSet" and add a comment to the former //NOT a set. Another thing that would help is comments to declare the different phases of this method... like definitely before the switch(docValuesType) and at other junctures. But I already see some code duplication in how numericProducer & binaryProducer are initialized. Here's an idea: Maybe Info could be changed to hold this state mutably. Then, there wouldn't be a long stage of pulling out each var from the info only to put it all back again. If this idea is successful, there would be much fewer local variables, and then you could easily extract a method to handle the DV stuff and a separate method for the Terms stuff. What do you think?
        • instead of freeze() knowing to call both getNormDocValues & prepareDocValues (and to sort terms), I suggest that freeze be implemented on each Info where those methods can be called there. I think that's easier to maintain.

        ... to be continued; I didn't finish reviewing ...

        Show
        dsmiley David Smiley added a comment - Returning the same doc values instance for binary, sorted, number and sorted number doc values is fine, but not for sorted set doc values. Good point. Some comments: addField: unfortunately this method is very long and it's difficult to follow. I understand that it's not easy to split it up because of the number of local variables. One thing that would help is renaming "longValues" and "bytesValuesSet" to make them clearly associated with doc-values. I suggest "dvLongValues" and "dvBytesValuesSet" and add a comment to the former //NOT a set . Another thing that would help is comments to declare the different phases of this method... like definitely before the switch(docValuesType) and at other junctures. But I already see some code duplication in how numericProducer & binaryProducer are initialized. Here's an idea: Maybe Info could be changed to hold this state mutably. Then, there wouldn't be a long stage of pulling out each var from the info only to put it all back again. If this idea is successful, there would be much fewer local variables, and then you could easily extract a method to handle the DV stuff and a separate method for the Terms stuff. What do you think? instead of freeze() knowing to call both getNormDocValues & prepareDocValues (and to sort terms), I suggest that freeze be implemented on each Info where those methods can be called there. I think that's easier to maintain. ... to be continued; I didn't finish reviewing ...
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Good idea, changing the state to be mutable in the Info class allowed for splitting this big method up into 2 smaller methods.

        I updated the patch. This looks much better now.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Good idea, changing the state to be mutable in the Info class allowed for splitting this big method up into 2 smaller methods. I updated the patch. This looks much better now.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Good idea, changing the state to be mutable in the Info class allowed for splitting this big method up into 2 smaller methods.

        I updated the patch. This looks much better now.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Good idea, changing the state to be mutable in the Info class allowed for splitting this big method up into 2 smaller methods. I updated the patch. This looks much better now.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Small update:

        • Moved the doc values prepare state to Info class
        • Use spare BytesRef in BinaryDocValuesProducer to fetch binary / sorted / sorted set DV.
        Show
        martijn.v.groningen Martijn van Groningen added a comment - Small update: Moved the doc values prepare state to Info class Use spare BytesRef in BinaryDocValuesProducer to fetch binary / sorted / sorted set DV.
        Hide
        dsmiley David Smiley added a comment -

        I really like how this refactor has turned out of making Info mutable.

        • I think the javadocs sentence you added to addField meant to use "if" not "is".
        • In getInfoForExpectedDocValuesType(), the two checks using (info.fieldInfo.getDocValuesType() read a little weird/confusing to me but I get the gist of the intent. Couldn't the first condition simply check expectedType == DocValuesType.NONE to return null? That's logically the same I think and could even be checked at the very front of the method.
        • getSortedSetDocValues's impl ought to reset index to 0 on setDocument().
        • getDocsWithField doesn't need to actually implement a bits, it can use return new Bits.MatchAllBits(1);
        • I think there's a bug in addField's positionIncrementGap & offsetGap handling. If fields are added to MemoryIndex that are DV then terms data, the posInc & offset will get incremented when it shouldn't be. This could be corrected by checking info.numTokens. Please modify or add a test for this. The boost should be applied conditionally as well (only when storeTerms is invoked).
        • storeDocValues(): for SORTED_NUMERIC I'm concerned about that growing algorithim... it's O(N^2) as it creates a new array each time that is just one larger. Ouch. Maybe use a straight-forward array doubling algorithm and keep track of the number of values?
        • It's a shame that SORTED & BINARY use a BytesRefHash (adds overhead) and ultimately get sorted when, really, it's not necessary of course. The ByteBlockPool could be used directly to store it (see BytesRefArray for examples) with a little bit of code. This isn't a blocker but it would sure be nice.
        • testDocValues() should test non-set behavior of sorted numerics, and set behavior of sorted set DV. Could be done easily by changing or adding a couple lines of code. Add term text here too, and under same field names as DV ones at that.
        Show
        dsmiley David Smiley added a comment - I really like how this refactor has turned out of making Info mutable. I think the javadocs sentence you added to addField meant to use "if" not "is". In getInfoForExpectedDocValuesType() , the two checks using (info.fieldInfo.getDocValuesType() read a little weird/confusing to me but I get the gist of the intent. Couldn't the first condition simply check expectedType == DocValuesType.NONE to return null? That's logically the same I think and could even be checked at the very front of the method. getSortedSetDocValues's impl ought to reset index to 0 on setDocument(). getDocsWithField doesn't need to actually implement a bits, it can use return new Bits.MatchAllBits(1); I think there's a bug in addField's positionIncrementGap & offsetGap handling. If fields are added to MemoryIndex that are DV then terms data, the posInc & offset will get incremented when it shouldn't be. This could be corrected by checking info.numTokens. Please modify or add a test for this. The boost should be applied conditionally as well (only when storeTerms is invoked). storeDocValues() : for SORTED_NUMERIC I'm concerned about that growing algorithim... it's O(N^2) as it creates a new array each time that is just one larger. Ouch. Maybe use a straight-forward array doubling algorithm and keep track of the number of values? It's a shame that SORTED & BINARY use a BytesRefHash (adds overhead) and ultimately get sorted when, really, it's not necessary of course. The ByteBlockPool could be used directly to store it (see BytesRefArray for examples) with a little bit of code. This isn't a blocker but it would sure be nice. testDocValues() should test non-set behavior of sorted numerics, and set behavior of sorted set DV. Could be done easily by changing or adding a couple lines of code. Add term text here too, and under same field names as DV ones at that.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Updated the patch with the good points that you've raised.

        It's a shame that SORTED & BINARY use a BytesRefHash (adds overhead) and ultimately get sorted when, really, it's not necessary of course. The ByteBlockPool could be used directly to store it (see BytesRefArray for examples) with a little bit of code. This isn't a blocker but it would sure be nice.

        Agreed, that would be nicer. I think we should do this in a follow up issue.

        Add term text here too, and under same field names as DV ones at that.

        I think this is covered in TestMemoryIndexAgainstRAMDir#testDocValuesMemoryIndexVsNormalIndex() test, in this test regular fields are randomilly added.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Updated the patch with the good points that you've raised. It's a shame that SORTED & BINARY use a BytesRefHash (adds overhead) and ultimately get sorted when, really, it's not necessary of course. The ByteBlockPool could be used directly to store it (see BytesRefArray for examples) with a little bit of code. This isn't a blocker but it would sure be nice. Agreed, that would be nicer. I think we should do this in a follow up issue. Add term text here too, and under same field names as DV ones at that. I think this is covered in TestMemoryIndexAgainstRAMDir#testDocValuesMemoryIndexVsNormalIndex() test, in this test regular fields are randomilly added.
        Hide
        dsmiley David Smiley added a comment -

        Almost there...

        • (still applies to the other addField): I think the javadocs sentence you added to addField meant to use "if" not "is".
        • At first I thought there might have been a bug for double-applying the boost since I see you're still passing "boost" as a constructor argument to Info. But now I see you only apply when numTokens > 0. I think it would be much clearer (and simpler) to remove boost from the constructor to Info, and simply apply it in storeTerms (no matter what numTokens is). It's hard to judge the testDocValuesDoNotAffectBoostPositionsOrOffset for this problem... it'd get encoded in the norm and I have no idea what norm it should be; your test asserts -127. Hmmmm. Perhaps simply leave a check of that nature to the test that asserts parity with the real index in RAMDirectory
        • in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the array. This results in the same O(N^2) we're trying to avoid! Pass in a second argument of the desired length.
        Show
        dsmiley David Smiley added a comment - Almost there... (still applies to the other addField): I think the javadocs sentence you added to addField meant to use "if" not "is". At first I thought there might have been a bug for double-applying the boost since I see you're still passing "boost" as a constructor argument to Info. But now I see you only apply when numTokens > 0. I think it would be much clearer (and simpler) to remove boost from the constructor to Info, and simply apply it in storeTerms (no matter what numTokens is). It's hard to judge the testDocValuesDoNotAffectBoostPositionsOrOffset for this problem... it'd get encoded in the norm and I have no idea what norm it should be; your test asserts -127. Hmmmm. Perhaps simply leave a check of that nature to the test that asserts parity with the real index in RAMDirectory in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the array. This results in the same O(N^2) we're trying to avoid! Pass in a second argument of the desired length.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        > in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the array. This results in the same O(N^2) we're trying to avoid! Pass in a second argument of the desired length.

        Maybe I was a bit concerned about the size of these arrays. ArrayUtil.grow(array) grows an array by an 1/8th and at least adds 3 additional slots, I thought that would be enough, since we don't know upfront how many new values are going to be added. I can change it double the array instead.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - > in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the array. This results in the same O(N^2) we're trying to avoid! Pass in a second argument of the desired length. Maybe I was a bit concerned about the size of these arrays. ArrayUtil.grow(array) grows an array by an 1/8th and at least adds 3 additional slots, I thought that would be enough, since we don't know upfront how many new values are going to be added. I can change it double the array instead.
        Hide
        dsmiley David Smiley added a comment -

        My main concern is that it not be O(N^2). Personally I'm not too concerned with ArrayUtil.grow's algorithm. You might also pick an initial size of something like '4' for the SORTED_NUMERIC case (since it implies the intent to add more than 1). With MemoryIndex I think speed is generally more important than memory size any way.

        Show
        dsmiley David Smiley added a comment - My main concern is that it not be O(N^2). Personally I'm not too concerned with ArrayUtil.grow's algorithm. You might also pick an initial size of something like '4' for the SORTED_NUMERIC case (since it implies the intent to add more than 1). With MemoryIndex I think speed is generally more important than memory size any way.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Right, speed over memory, I'll change it to the doubling logic you initially suggested.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Right, speed over memory, I'll change it to the doubling logic you initially suggested.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Updated the patch.

        (still applies to the other addField): I think the javadocs sentence you added to addField meant to use "if" not "is".

        Changed.

        At first I thought there might have been a bug for double-applying the boost since I see you're still passing "boost" as a constructor argument to Info. But now I see you only apply when numTokens > 0. I think it would be much clearer (and simpler) to remove boost from the constructor to Info, and simply apply it in storeTerms (no matter what numTokens is). It's hard to judge the testDocValuesDoNotAffectBoostPositionsOrOffset for this problem... it'd get encoded in the norm and I have no idea what norm it should be; your test asserts -127. Hmmmm. Perhaps simply leave a check of that nature to the test that asserts parity with the real index in RAMDirectory

        Removed the boost constructor parameter and added a dedicated test for this in TestMemoryIndexAgainstRAMDir.

        in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the array. This results in the same O(N^2) we're trying to avoid! Pass in a second argument of the desired length.

        Changed, the size is array doubled when growing is necessary.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Updated the patch. (still applies to the other addField): I think the javadocs sentence you added to addField meant to use "if" not "is". Changed. At first I thought there might have been a bug for double-applying the boost since I see you're still passing "boost" as a constructor argument to Info. But now I see you only apply when numTokens > 0. I think it would be much clearer (and simpler) to remove boost from the constructor to Info, and simply apply it in storeTerms (no matter what numTokens is). It's hard to judge the testDocValuesDoNotAffectBoostPositionsOrOffset for this problem... it'd get encoded in the norm and I have no idea what norm it should be; your test asserts -127. Hmmmm. Perhaps simply leave a check of that nature to the test that asserts parity with the real index in RAMDirectory Removed the boost constructor parameter and added a dedicated test for this in TestMemoryIndexAgainstRAMDir. in storeDocValues() SORTED_NUMERIC: you call ArrayUtil.grow with only the array. This results in the same O(N^2) we're trying to avoid! Pass in a second argument of the desired length. Changed, the size is array doubled when growing is necessary.
        Hide
        dsmiley David Smiley added a comment -

        Eh, the grow algorithm/code still isn't right. The code in the patch will double the size even though it's likely plenty big to add the current long trying to get added. This is what I mean:

              case SORTED_NUMERIC:
                if (info.numericProducer.dvLongValues == null) {
                  info.numericProducer.dvLongValues = new long[4];
                }
                info.numericProducer.dvLongValues = ArrayUtil.grow(info.numericProducer.dvLongValues, info.numericProducer.count + 1);
                info.numericProducer.dvLongValues[info.numericProducer.count++] = (long) docValuesValue;
                break;
        

        Everything else is good. Assuming you agree with this code snippet above, +1 from me to commit.

        Show
        dsmiley David Smiley added a comment - Eh, the grow algorithm/code still isn't right. The code in the patch will double the size even though it's likely plenty big to add the current long trying to get added. This is what I mean: case SORTED_NUMERIC: if (info.numericProducer.dvLongValues == null ) { info.numericProducer.dvLongValues = new long [4]; } info.numericProducer.dvLongValues = ArrayUtil.grow(info.numericProducer.dvLongValues, info.numericProducer.count + 1); info.numericProducer.dvLongValues[info.numericProducer.count++] = ( long ) docValuesValue; break ; Everything else is good. Assuming you agree with this code snippet above, +1 from me to commit.
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Ah, that makes more sense. I misunderstood what you meant earlier. I've updated the patch. Thank you for this thorough review!

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Ah, that makes more sense. I misunderstood what you meant earlier. I've updated the patch. Thank you for this thorough review!
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        I'll backport this change to 6.0 and 6.x branches. Otherwise LUCENE-7093 can't be backported and that would be bad as simple queries on numeric fields wouldn't work anymore, since numerics have moved to use points instead.

        Because of this I'll backport LUCENE-7087 to 6.0 too.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - I'll backport this change to 6.0 and 6.x branches. Otherwise LUCENE-7093 can't be backported and that would be bad as simple queries on numeric fields wouldn't work anymore, since numerics have moved to use points instead. Because of this I'll backport LUCENE-7087 to 6.0 too.
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit bd0803fd41c68297c54201529c2c14ad50cda48e in lucene-solr's branch refs/heads/branch_6_0 from Martijn van Groningen
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bd0803f ]

        LUCENE-7091: Added doc values support to memory index

        Show
        jira-bot ASF subversion and git services added a comment - Commit bd0803fd41c68297c54201529c2c14ad50cda48e in lucene-solr's branch refs/heads/branch_6_0 from Martijn van Groningen [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bd0803f ] LUCENE-7091 : Added doc values support to memory index
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 559432fcdcd828864a800072cf144e1f5c96647e in lucene-solr's branch refs/heads/branch_6x from Martijn van Groningen
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=559432f ]

        LUCENE-7091: Added doc values support to memory index

        Show
        jira-bot ASF subversion and git services added a comment - Commit 559432fcdcd828864a800072cf144e1f5c96647e in lucene-solr's branch refs/heads/branch_6x from Martijn van Groningen [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=559432f ] LUCENE-7091 : Added doc values support to memory index
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit cf3eea26406692306505d2606d7ff73ee3634c30 in lucene-solr's branch refs/heads/master from Martijn van Groningen
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf3eea2 ]

        LUCENE-7091: Added doc values support to memory index

        Show
        jira-bot ASF subversion and git services added a comment - Commit cf3eea26406692306505d2606d7ff73ee3634c30 in lucene-solr's branch refs/heads/master from Martijn van Groningen [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf3eea2 ] LUCENE-7091 : Added doc values support to memory index
        Hide
        martijn.v.groningen Martijn van Groningen added a comment -

        Pushed to master, branch_6x and branch_6_0 branches.

        Show
        martijn.v.groningen Martijn van Groningen added a comment - Pushed to master, branch_6x and branch_6_0 branches.

          People

          • Assignee:
            martijn.v.groningen Martijn van Groningen
            Reporter:
            martijn.v.groningen Martijn van Groningen
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development