-
-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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
|
@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