False postive EAGER queries are being reported when more than one proxy is in the application stack. For example, a Spring RMI layer in front of the Spring Data Repository call. The RMI layer would be the top-most proxy and be detected first, resulting in isolated/unrelated query methods being considered for eager fetches. The code here increments based on the proxy name, which is detected incorrectly. This seems to stem from the code in getProxyMethodName()
Why did you choose to walk the stack backward (top-down), vs starting at the bottom and going up? If it were reversed, wouldn't it find the more accurate proxy method or would that lead to missed detections?
This is possibly related to #26, but not isolated to testing.
Consider improving the proxy detection by doing one of the following:
reverse the proxy find order so we take bottom-most proxy from the stack
take the first proxy found in the stack, but only after seeing org.springframework.transaction.interceptor.TransactionInterceptor
provide some kind of automatic proxy name filtering based on declared Repository classes
provide some kind of manual proxy name filtering (include and exclude) to allow manual config for these special cases
False postive EAGER queries are being reported when more than one proxy is in the application stack. For example, a Spring RMI layer in front of the Spring Data Repository call. The RMI layer would be the top-most proxy and be detected first, resulting in isolated/unrelated query methods being considered for eager fetches. The code here increments based on the proxy name, which is detected incorrectly. This seems to stem from the code in getProxyMethodName()
Why did you choose to walk the stack backward (top-down), vs starting at the bottom and going up? If it were reversed, wouldn't it find the more accurate proxy method or would that lead to missed detections?
This is possibly related to #26, but not isolated to testing.
Consider improving the proxy detection by doing one of the following: