[ https://issues.apache.org/jira/browse/OAK-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771825#comment-16771825 ]
Julian Reschke edited comment on OAK-8035 at 2/19/19 11:18 AM: --------------------------------------------------------------- {quote}[~reschke] - Just find it a bit more fluent with assertions - makes the test code a bit more clean to look at and I used the version that I had used before to make sure it works as I expect . But I can remove it - I also need to refactor the test to use the LogCustomizer as you suggested - so will remove this dependency also along with that. {quote} Done that already, and I don't thik the test is harder to read. See [r1853872|http://svn.apache.org/r1853872]. bq. But just for my future reference - do we not introduce any new test dependencies in oak ? or is there some RTC process that I bypassed and needed to follow before introducing one ? No, adding new test dependencies is fine. We just should do it consciously and coordinated. My preference would be not to add new dependencies just because somebody liked a particular library. In the end, the whole team needs to be able to support the code in the future. was (Author: reschke): {quote}[~reschke] - Just find it a bit more fluent with assertions - makes the test code a bit more clean to look at and I used the version that I had used before to make sure it works as I expect . But I can remove it - I also need to refactor the test to use the LogCustomizer as you suggested - so will remove this dependency also along with that. {quote} Done that already, and I don't thik the test is harder to read. See [r1853872|http://svn.apache.org/r1853872] bq. But just for my future reference - do we not introduce any new test dependencies in oak ? or is there some RTC process that I bypassed and needed to follow before introducing one ? No, adding new test dependencies is fine. We just should do it consciously and coordinated. My preference would be not to add new dependencies just because somebody liked a particular library. In the end, the whole team needs to be able to support the code in the future. > Debug logging when two or more indices have same or very close cost amounts > doesn't work in case both indices belong to the same type of Query Index > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: OAK-8035 > URL: https://issues.apache.org/jira/browse/OAK-8035 > Project: Jackrabbit Oak > Issue Type: Bug > Components: query > Reporter: Nitin Gupta > Assignee: Julian Reschke > Priority: Major > Fix For: 1.12, 1.11.0 > > Attachments: OAK-8035.patch, OAK-8035_2.patch, OAK-8035_3.patch > > > Steps to reproduce - > # You would need two index definitions of same query index type , let's say > fullText index , having similar cost evaluations. > # Now while the index plan is evaluated you will notice that there should > have been a debug log saying that selected index has similar cost - this > serves as an important warning to either change the index definitions or the > query > ([https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryImpl.java#L1069#L1072)] > > However If we have a look at this code block here - > [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/QueryImpl.java#L1017#L1041] > , there is no comparison for near best costs for index plans having same > query index type . > > cc : [~teofili] -- This message was sent by Atlassian JIRA (v7.6.3#76005)