-
-
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
[refactor] Restructure RangeIndexAttributeCondition #5259
base: develop
Are you sure you want to change the base?
Conversation
- only keep operator and two flags in memor - value, lowercasevalue and numericvalue were replaced by two functions - indexPredicate and queryPredicate
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.
Ony a small change found ;-)
...indexes/range/src/main/java/org/exist/indexing/range/RangeIndexConfigAttributeCondition.java
Outdated
Show resolved
Hide resolved
Quality Gate failedFailed conditions |
@reinhapa I believe the changes you requested were addressed in the meantime |
@reinhapa could you please re-review, I believe it's good 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.
I am not sure if this also addresses a bug or not? If it is just refactoring of existing code, then I have concerns:
- The newer code is more complex and difficult to follow; I don't see what advantage it offers over the existing code.
- The newer code exhibits symptoms of "information hiding". e.g. the variable
caseSensitive
(amongst others) is no longer knowable within an instance of the class at runtime; one side effect of that is that it will make debugging any future issues much more difficult. - I haven't tested it with JMH myself, but my intuition is that the new code will perform worse that the older code. Has this been tested with JMH yet?
} | ||
operator = getOperator(elem); | ||
commutative = (operator == Operator.EQ || operator == Operator.NE); | ||
commutativeNegate = (operator == Operator.GT || operator == Operator.LT || operator == Operator.GE || operator == Operator.LE); |
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.
commutativeNegate
is a very strange name, at least in English. Perhaps notCommutative
would be better to describe what you are trying to model?
commutativeNegate could be renamed to converse (see https://en.m.wikipedia.org/wiki/Converse_relation and https://en.m.wikipedia.org/wiki/Inequality_(mathematics) ). |
Description:
These private properties of RangeIndexAttributeCondition
were replaced by
indexPredicate and queryPredicate are references to one-line lambdas.
Before, a lot of switching and checking happened on each call to
find
andmatches