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

Add GraphTermsQuery to limit traversal on high frequency nodes

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Implemented
    • Affects Version/s: None
    • Fix Version/s: 6.1
    • Component/s: None
    • Labels:
      None

      Description

      The gatherNodes() Streaming Expression is currently using a basic disjunction query to perform the traversals. This ticket is to create a specific GraphTermsQuery for performing the traversals.

      The GraphTermsQuery will be based off of the TermsQuery, but will also include an option for a docFreq cutoff. Terms that are above the docFreq cutoff will not be included in the query. This will help users do a more precise and efficient traversal.

      1. SOLR-9027.patch
        18 kB
        Joel Bernstein
      2. SOLR-9027.patch
        17 kB
        Joel Bernstein
      3. SOLR-9027.patch
        12 kB
        Joel Bernstein
      4. SOLR-9027.patch
        7 kB
        Joel Bernstein

        Issue Links

          Activity

          Hide
          joel.bernstein Joel Bernstein added a comment - - edited

          Basic implementation. Tests still needed.

          It doesn't do anything fancy to build up the matching docs. The main thing that it adds is the maxDocFreq param which is the threshold for discarding query terms.

          This essentially creates an on-the-fly stop list for high frequency nodes that appear during a graph traversal.

          Show
          joel.bernstein Joel Bernstein added a comment - - edited Basic implementation. Tests still needed. It doesn't do anything fancy to build up the matching docs. The main thing that it adds is the maxDocFreq param which is the threshold for discarding query terms. This essentially creates an on-the-fly stop list for high frequency nodes that appear during a graph traversal.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Simple test cases that shows the maxDocFreq param working. I'll expand on these and do some manual testing for performance.

          Show
          joel.bernstein Joel Bernstein added a comment - Simple test cases that shows the maxDocFreq param working. I'll expand on these and do some manual testing for performance.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Actually more tests have shown that I'm not collecting the docFreq properly. I'll need to take the exact same approach as the CommonTermsQuery in doing this. More work to do here.

          Show
          joel.bernstein Joel Bernstein added a comment - Actually more tests have shown that I'm not collecting the docFreq properly. I'll need to take the exact same approach as the CommonTermsQuery in doing this. More work to do here.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          New patch that gathers the TermContexts in the rewrite method.

          Show
          joel.bernstein Joel Bernstein added a comment - New patch that gathers the TermContexts in the rewrite method.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Filled in the test cases a little bit more.

          Show
          joel.bernstein Joel Bernstein added a comment - Filled in the test cases a little bit more.
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          SOLR-9027: Add GraphTermsQuery to limit traversal on high frequency nodes

          Show
          jira-bot ASF subversion and git services added a comment - Commit d66f5515e648bdf52f3ea36ae76af72742a95336 in lucene-solr's branch refs/heads/master from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d66f551 ] SOLR-9027 : Add GraphTermsQuery to limit traversal on high frequency nodes
          Hide
          dsmiley David Smiley added a comment -

          I took a peek at what you committed out of curiosity.

          • why wrap each BytesRef in a Term when in the end you just need the BytesRef? Or maybe I'm mistaken.
          • equals and hashcode is on id yet you initialize that to new Object(). Firstly; why not have equals/hashcode actually work? Secondly, if for some reason it should be this way, then you can do away with id and do equals on instance equality of the query instance – you don't need id.
          • Query fields should be 'final' to emphasize immutability.
          • I think it's very suspicious that GraphTermsQuery holds List<TermContext>; I think the Query object should not hold state pertaining to the actual index as it could cause issues with caching. Maybe you could do the construction of this in createWeight and hold it on the Weight?
          • collectTermContext: assuming just one field is actually supported, this could avoid looking up a Terms for each query terms since it'd always be the same.
          • in no place do I see you sort the incoming terms. It's faster to seek sequentially and not randomly.
          Show
          dsmiley David Smiley added a comment - I took a peek at what you committed out of curiosity. why wrap each BytesRef in a Term when in the end you just need the BytesRef? Or maybe I'm mistaken. equals and hashcode is on id yet you initialize that to new Object() . Firstly; why not have equals/hashcode actually work? Secondly, if for some reason it should be this way, then you can do away with id and do equals on instance equality of the query instance – you don't need id. Query fields should be 'final' to emphasize immutability. I think it's very suspicious that GraphTermsQuery holds List<TermContext>; I think the Query object should not hold state pertaining to the actual index as it could cause issues with caching. Maybe you could do the construction of this in createWeight and hold it on the Weight? collectTermContext: assuming just one field is actually supported, this could avoid looking up a Terms for each query terms since it'd always be the same. in no place do I see you sort the incoming terms. It's faster to seek sequentially and not randomly.
          Hide
          joel.bernstein Joel Bernstein added a comment - - edited

          why wrap each BytesRef in a Term when in the end you just need the BytesRef? Or maybe I'm mistaken.

          I haven't really optimized things yet. I'll take a look at optimizing this.

          equals and hashcode is on id yet you initialize that to new Object(). Firstly; why not have equals/hashcode actually work? Secondly, if for some reason it should be this way, then you can do away with id and do equals on instance equality of the query instance – you don't need id.

          It's designed to only be equal on identity so it doesn't cache. The main reason for this is that graph traversals are typically one time jobs so I wanted to avoid the overhead of hashcode and equals on large term lists.There may be a better approach to the identity equality, so I'll review your suggestion.

          I think it's very suspicious that GraphTermsQuery holds List<TermContext>; I think the Query object should not hold state pertaining to the actual index as it could cause issues with caching. Maybe you could do the construction of this in createWeight and hold it on the Weight?

          This sounds like a good idea.

          in no place do I see you sort the incoming terms. It's faster to seek sequentially and not randomly.

          It appeared that the TermsQuery was sorting terms to account for different fields. But the GraphTermsQuery is always on one field. Since it's always doing a seekExact, I was assuming that it would always have to seek from the top of the terms enum anyway, because it can't make assumptions on the order of the terms. In this case it would seem sorting would just add overhead. But I could be wrong about this.

          Show
          joel.bernstein Joel Bernstein added a comment - - edited why wrap each BytesRef in a Term when in the end you just need the BytesRef? Or maybe I'm mistaken. I haven't really optimized things yet. I'll take a look at optimizing this. equals and hashcode is on id yet you initialize that to new Object(). Firstly; why not have equals/hashcode actually work? Secondly, if for some reason it should be this way, then you can do away with id and do equals on instance equality of the query instance – you don't need id. It's designed to only be equal on identity so it doesn't cache. The main reason for this is that graph traversals are typically one time jobs so I wanted to avoid the overhead of hashcode and equals on large term lists.There may be a better approach to the identity equality, so I'll review your suggestion. I think it's very suspicious that GraphTermsQuery holds List<TermContext>; I think the Query object should not hold state pertaining to the actual index as it could cause issues with caching. Maybe you could do the construction of this in createWeight and hold it on the Weight? This sounds like a good idea. in no place do I see you sort the incoming terms. It's faster to seek sequentially and not randomly. It appeared that the TermsQuery was sorting terms to account for different fields. But the GraphTermsQuery is always on one field. Since it's always doing a seekExact, I was assuming that it would always have to seek from the top of the terms enum anyway, because it can't make assumptions on the order of the terms. In this case it would seem sorting would just add overhead. But I could be wrong about this.
          Hide
          dsmiley David Smiley added a comment -

          Some TermsEnum impls, including the default one, are optimized for the case of seeking forward from the current position. At least it was the last I checked.

          Show
          dsmiley David Smiley added a comment - Some TermsEnum impls, including the default one, are optimized for the case of seeking forward from the current position. At least it was the last I checked.
          Hide
          joel.bernstein Joel Bernstein added a comment - - edited

          Ok, I didn't realize that. So they must start from where they left off and wrap-around? If thats the case then sorting will definitely be faster. I'll add the sort.

          Show
          joel.bernstein Joel Bernstein added a comment - - edited Ok, I didn't realize that. So they must start from where they left off and wrap-around? If thats the case then sorting will definitely be faster. I'll add the sort.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          David Smiley, I was looking at the TermContext issue that you brought up. As long as the TermContext is not part of the Cache key, it should be ok to hang onto it in the query. I put a comment into rewrite about this. So I think we're safe the way it's being used. Also rewrite seems like a nice place to gather the TermContexts. But if you feel strongly that the Query should not hold any index state I can still move this code to createWeight.

          Show
          joel.bernstein Joel Bernstein added a comment - David Smiley , I was looking at the TermContext issue that you brought up. As long as the TermContext is not part of the Cache key, it should be ok to hang onto it in the query. I put a comment into rewrite about this. So I think we're safe the way it's being used. Also rewrite seems like a nice place to gather the TermContexts. But if you feel strongly that the Query should not hold any index state I can still move this code to createWeight.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Also thanks for reviewing!

          Show
          joel.bernstein Joel Bernstein added a comment - Also thanks for reviewing!
          Hide
          dsmiley David Smiley added a comment -

          Because this query is intentionally non-cacheable (unlike just about all other Query's) I think it's okay to get away with putting the TermContexts on the Query. I wouldn't do it out of principle unless there was no other reasonable way, but that's me. Maybe the fact that it's not cached could be made more explicit to others reading the code. Might you implement ExtendedQuery to to have getCache return true to make this more guaranteed?

          Also thanks for reviewing!

          no prob. sorry for not providing input before you committed.

          Show
          dsmiley David Smiley added a comment - Because this query is intentionally non-cacheable (unlike just about all other Query's) I think it's okay to get away with putting the TermContexts on the Query. I wouldn't do it out of principle unless there was no other reasonable way, but that's me. Maybe the fact that it's not cached could be made more explicit to others reading the code. Might you implement ExtendedQuery to to have getCache return true to make this more guaranteed? Also thanks for reviewing! no prob. sorry for not providing input before you committed.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Ok, I'll do one more round of work on this in master before back porting to 6x and I'll try to roll-in all your suggestions.

          Show
          joel.bernstein Joel Bernstein added a comment - Ok, I'll do one more round of work on this in master before back porting to 6x and I'll try to roll-in all your suggestions.
          Hide
          kwatters Kevin Watters added a comment -

          Nice stuff Joel! Just a thought, it might be nice to also provide a "maxDocFreq" on the GraphTermsQuery... relatively easy to add now, and it would allow graph traversal that ignore sparse edges...

          Either way, this is very cool, It seems like this would be a natural enhancement for the GraphQuery when it builds the frontier.

          Show
          kwatters Kevin Watters added a comment - Nice stuff Joel! Just a thought, it might be nice to also provide a "maxDocFreq" on the GraphTermsQuery... relatively easy to add now, and it would allow graph traversal that ignore sparse edges... Either way, this is very cool, It seems like this would be a natural enhancement for the GraphQuery when it builds the frontier.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Thanks!

          The GraphTermsQuery has a maxDocFreq param, did you mean a minDocFreq?

          Show
          joel.bernstein Joel Bernstein added a comment - Thanks! The GraphTermsQuery has a maxDocFreq param, did you mean a minDocFreq?
          Hide
          kwatters Kevin Watters added a comment -

          Yes, sorry for the typo, minDocFreq avoid sparse edges .. could be a useful use case.. (especially in a distributed use case)

          Show
          kwatters Kevin Watters added a comment - Yes, sorry for the typo, minDocFreq avoid sparse edges .. could be a useful use case.. (especially in a distributed use case)
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Sure, this would be easy to add. I was having a hard time thinking of the use cases though. Are there scenarios where nodes with low document frequencies are better to skip?

          Show
          joel.bernstein Joel Bernstein added a comment - Sure, this would be easy to add. I was having a hard time thinking of the use cases though. Are there scenarios where nodes with low document frequencies are better to skip?
          Hide
          kwatters Kevin Watters added a comment -

          no specific use case.. but if doc frequency is 0 for a given term in a "node/from" field, there's not much point in traversing it,or querying for it in the first place. I'm not sure if that's even possible, but you might have edges that point to a document that doesn't exist, in such a case, it's an easy optimization to avoid that traversal. (similar to the leafNodesOnly parameter on the GraphQuery.)

          Show
          kwatters Kevin Watters added a comment - no specific use case.. but if doc frequency is 0 for a given term in a "node/from" field, there's not much point in traversing it,or querying for it in the first place. I'm not sure if that's even possible, but you might have edges that point to a document that doesn't exist, in such a case, it's an easy optimization to avoid that traversal. (similar to the leafNodesOnly parameter on the GraphQuery.)
          Hide
          joel.bernstein Joel Bernstein added a comment - - edited

          David Smiley, I've been working on the changes you proposed. I dug into how the TermContext is being used elsewhere in Lucene. What I found was that the TermQuery is holding onto the TermContext and seems to be relying on wrapper queries to manage it properly. This is marked as an expert usage. The CommonTermsQuery uses this constructor. So it does appear that holding onto the TermContext is OK, as long as it's handled properly. So I'll review just to make sure the TermContexts are always regenerated when the query is run and continue to hold onto it within the query.

          Show
          joel.bernstein Joel Bernstein added a comment - - edited David Smiley , I've been working on the changes you proposed. I dug into how the TermContext is being used elsewhere in Lucene. What I found was that the TermQuery is holding onto the TermContext and seems to be relying on wrapper queries to manage it properly. This is marked as an expert usage. The CommonTermsQuery uses this constructor. So it does appear that holding onto the TermContext is OK, as long as it's handled properly. So I'll review just to make sure the TermContexts are always regenerated when the query is run and continue to hold onto it within the query.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 2c66d4b04619e5ac3ddf6984aacd833a62c33a29 in lucene-solr's branch refs/heads/master from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2c66d4b ]

          SOLR-9027: GraphTermsQuery optimizations and more explicit handling of non-caching behavior

          Show
          jira-bot ASF subversion and git services added a comment - Commit 2c66d4b04619e5ac3ddf6984aacd833a62c33a29 in lucene-solr's branch refs/heads/master from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2c66d4b ] SOLR-9027 : GraphTermsQuery optimizations and more explicit handling of non-caching behavior
          Hide
          dsmiley David Smiley added a comment -

          I dug into how the TermContext is being used elsewhere in Lucene. What I found was that the TermQuery is holding onto the TermContext and seems to be relying on wrapper queries to manage it properly. This is marked as an expert usage. The CommonTermsQuery uses this constructor. So it does appear that holding onto the TermContext is OK, as long as it's handled properly.

          Okay. AFAICT, the only reason TermQuery.perReaderTermState exists is because some callers just so happen to already have the TermContext, so this saves getting it later. In the case of GraphTermsQuery the QParser does not and has no reason to get the TermContext in advance.

          Show
          dsmiley David Smiley added a comment - I dug into how the TermContext is being used elsewhere in Lucene. What I found was that the TermQuery is holding onto the TermContext and seems to be relying on wrapper queries to manage it properly. This is marked as an expert usage. The CommonTermsQuery uses this constructor. So it does appear that holding onto the TermContext is OK, as long as it's handled properly. Okay. AFAICT, the only reason TermQuery.perReaderTermState exists is because some callers just so happen to already have the TermContext, so this saves getting it later. In the case of GraphTermsQuery the QParser does not and has no reason to get the TermContext in advance.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Good point, I may take one more pass at refactoring before back porting.

          Show
          joel.bernstein Joel Bernstein added a comment - Good point, I may take one more pass at refactoring before back porting.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 58ad591a643e4c48a51d2ca9039b4889a789dbde in lucene-solr's branch refs/heads/master from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=58ad591 ]

          SOLR-9027: Collect the TermContexts in createWeight

          Show
          jira-bot ASF subversion and git services added a comment - Commit 58ad591a643e4c48a51d2ca9039b4889a789dbde in lucene-solr's branch refs/heads/master from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=58ad591 ] SOLR-9027 : Collect the TermContexts in createWeight
          Hide
          joel.bernstein Joel Bernstein added a comment - - edited

          Ok, I moved the TermContext collection into createWeight, so no more hanging onto the TermContexts in the Query object.

          Thanks David Smiley, for the suggestions! I plan to do some more manual testing at scale and then backport to 6x.

          Show
          joel.bernstein Joel Bernstein added a comment - - edited Ok, I moved the TermContext collection into createWeight, so no more hanging onto the TermContexts in the Query object. Thanks David Smiley , for the suggestions! I plan to do some more manual testing at scale and then backport to 6x.
          Hide
          dsmiley David Smiley added a comment -

          Nice Joel Bernstein.

          BTW about collectTermContext, to be more clear on what I said earlier, which may have been overlooked – we're calling fields.terms(term.field()) on every single term given. But they will all be the same as this is used for just one field. Even if we wanted to support multiple fields, this terms variable could be declared outside the loop and then only re-fetch if the current field for this loop iteration is different than that of the previous. Granted I don't know if a lot of terms is normal or the rare case for GraphTermsQuery but I suspect a lot. This is another reason for the sort I advocated for.

          Show
          dsmiley David Smiley added a comment - Nice Joel Bernstein . BTW about collectTermContext, to be more clear on what I said earlier, which may have been overlooked – we're calling fields.terms(term.field()) on every single term given. But they will all be the same as this is used for just one field. Even if we wanted to support multiple fields, this terms variable could be declared outside the loop and then only re-fetch if the current field for this loop iteration is different than that of the previous. Granted I don't know if a lot of terms is normal or the rare case for GraphTermsQuery but I suspect a lot. This is another reason for the sort I advocated for.
          Hide
          joel.bernstein Joel Bernstein added a comment -

          Yep, I see this. I'll make this change as well.

          Show
          joel.bernstein Joel Bernstein added a comment - Yep, I see this. I'll make this change as well.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 3d3c3fb5fc2db39f433c5f449d0bee81ef89a189 in lucene-solr's branch refs/heads/master from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3d3c3fb ]

          SOLR-9027: Pull the TermsEnum once for each segment

          Show
          jira-bot ASF subversion and git services added a comment - Commit 3d3c3fb5fc2db39f433c5f449d0bee81ef89a189 in lucene-solr's branch refs/heads/master from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3d3c3fb ] SOLR-9027 : Pull the TermsEnum once for each segment
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 06f9bd2bf9805309801824b5c97294a7d1d231ab in lucene-solr's branch refs/heads/branch_6x from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=06f9bd2 ]

          SOLR-9027: Add GraphTermsQuery to limit traversal on high frequency nodes

          Show
          jira-bot ASF subversion and git services added a comment - Commit 06f9bd2bf9805309801824b5c97294a7d1d231ab in lucene-solr's branch refs/heads/branch_6x from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=06f9bd2 ] SOLR-9027 : Add GraphTermsQuery to limit traversal on high frequency nodes
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 86f371cbc68f233697f9be8df93b707daf3826b4 in lucene-solr's branch refs/heads/branch_6x from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86f371c ]

          SOLR-9027: GraphTermsQuery optimizations and more explicit handling of non-caching behavior

          Show
          jira-bot ASF subversion and git services added a comment - Commit 86f371cbc68f233697f9be8df93b707daf3826b4 in lucene-solr's branch refs/heads/branch_6x from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86f371c ] SOLR-9027 : GraphTermsQuery optimizations and more explicit handling of non-caching behavior
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 3cc4125a8a04fb71be71b1eb1222a860d3d646e4 in lucene-solr's branch refs/heads/branch_6x from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3cc4125 ]

          SOLR-9027: Collect the TermContexts in createWeight

          Show
          jira-bot ASF subversion and git services added a comment - Commit 3cc4125a8a04fb71be71b1eb1222a860d3d646e4 in lucene-solr's branch refs/heads/branch_6x from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3cc4125 ] SOLR-9027 : Collect the TermContexts in createWeight
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 32f7d045d628ea29b358a1c1420f89f7e66865bf in lucene-solr's branch refs/heads/branch_6x from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=32f7d04 ]

          SOLR-9027: Pull the TermsEnum once for each segment

          Show
          jira-bot ASF subversion and git services added a comment - Commit 32f7d045d628ea29b358a1c1420f89f7e66865bf in lucene-solr's branch refs/heads/branch_6x from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=32f7d04 ] SOLR-9027 : Pull the TermsEnum once for each segment
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 62a28dd0c7dc8f41e43d5c37e28c968556b8e9d2 in lucene-solr's branch refs/heads/master from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=62a28dd ]

          SOLR-8986, SOLR-8925, SOLR-9027: Update CHANGES.txt

          Show
          jira-bot ASF subversion and git services added a comment - Commit 62a28dd0c7dc8f41e43d5c37e28c968556b8e9d2 in lucene-solr's branch refs/heads/master from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=62a28dd ] SOLR-8986 , SOLR-8925 , SOLR-9027 : Update CHANGES.txt
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit df72df1c58a5884774d003eec2f71c27a4737896 in lucene-solr's branch refs/heads/branch_6x from jbernste
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df72df1 ]

          SOLR-8986, SOLR-8925, SOLR-9027: Update CHANGES.txt

          Conflicts:
          solr/CHANGES.txt

          Show
          jira-bot ASF subversion and git services added a comment - Commit df72df1c58a5884774d003eec2f71c27a4737896 in lucene-solr's branch refs/heads/branch_6x from jbernste [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df72df1 ] SOLR-8986 , SOLR-8925 , SOLR-9027 : Update CHANGES.txt Conflicts: solr/CHANGES.txt
          Hide
          steve_rowe Steve Rowe added a comment -

          Reproducing NPE on TestGraphTermsQParserPlugin.testQueries(): SOLR-9254

          Show
          steve_rowe Steve Rowe added a comment - Reproducing NPE on TestGraphTermsQParserPlugin.testQueries() : SOLR-9254

            People

            • Assignee:
              Unassigned
              Reporter:
              joel.bernstein Joel Bernstein
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development