-
-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed fix for #3624 NPE at RangeQueryRewriter.rewriteLocationStep #3625
Proposed fix for #3624 NPE at RangeQueryRewriter.rewriteLocationStep #3625
Conversation
…RangeQueryRewriter.rewriteLocationStep Handle all operators
@dizzzz Interesting stuff... I have some questions ;-)
Lookup func = Lookup.create(function.getContext(), operator, path);
func.setArguments(eqArgs); The |
Instead of preventing the Hmmm did I miss a potential NPE? I thought I covered it all.... |
Hmmm, shouldn't |
Hmmmm you are right on this I guess. good spot. hmmmm |
What shall I do? close PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I debugged the original issue myself and came to the conclusion that Dannes' proposed fix is basically correct. What we have here is an expression which has already been partially rewritten (the GeneralComparison
was replaced by range:eq
). I'm not sure where this partial optimization was applied - probably an earlier traversal of the expression (we would need a much more reduced test case to know), but it is certainly a possible case which should not lead to an exception.
As Dannes pointed out, RangeQueryRewriter.rewrite
only handled matches
(stupid me!). It should handle all functions implementing Lookup
.
extensions/indexes/range/src/main/java/org/exist/xquery/modules/range/RangeQueryRewriter.java
Outdated
Show resolved
Hide resolved
extensions/indexes/range/src/main/java/org/exist/xquery/modules/range/RangeQueryRewriter.java
Show resolved
Hide resolved
…proposal_fix_npe_rangequeryrewriter * 'develop' of github.com:eXist-db/exist: (109 commits) Bump dependency-check-maven from 6.0.3 to 6.0.4 Wrong merge.... file needs to be deleted Fix for eXist-db#3688 Read buffer wrap file stream writes into BufferedOutputStreams. Remove old (unfinished?) code Bump rsyntaxtextarea from 3.1.1 to 3.1.2 Feedback from review: use explicit services file Feedback from Adam Bump bcprov-jdk15on from 1.67 to 1.68 Bump xmlunit.version from 2.8.1 to 2.8.2 Feedback from Codacy Feedback from Codacy Setting the dot. Improved text a bit Handle potential (and real) NPE; allow issue to be ignored. Only delete (overwrite) file if user explicitly agrees Bump jansi from 2.1.0 to 2.1.1 Reported by codacy Improve startup logging ...
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
@wolfgangmm @adamretter ready to go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dizzzz Thank you so much for this fix! And thanks to @adamretter and @wolfgangmm for your reviews. |
I just dug into this further to try and understand why this fix works. I reduced Dannes's changes to the absolute minimum to pass Joe's reported issue #3624, and was left with just this patch:
As @wolfgangmm hinted at previously, the statement The more I think about this, the less sense the current code makes. If we already have an instance of With that in mind I still think it likely that the current fix is addressing a symptom rather than the root cause of the problem, and that eXist-db is doing more work than necessary by replacing one optimized Lookup expression with exactly the same optimized Lookup expression. I will keep digging... |
We (Evolved Binary) have provided an updated PR that takes a more efficient path in - #4882 |
Proposed fix for #3624 NPE at org.exist.xquery.modules.range.RangeQueryRewriter.rewriteLocationStep
Handle all operators
Help needed for tests