Apache9 commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-642399063
> Caller has to take returned location, extract end row... do proper handling if end region... when they seems more natural to just call 'next' if it an iterator/scanner-like API. The point here is when do you want to do this? In normal single read/write path, we just need to locate a single region. And for scanning, we need to locate to the next region when the current region is done, or for reverse scan we need to locate to the previous region. We do not need to get the location of a region and then go to the next region. And we have a layered structure, in the read/write/scan code, they will call locate everytime when they want to know the location of a region, there is no prefetching, no caching, etc. The entry point is AsyncRegionLocator. And in AsyncRegionLocator and its related implementation classes, we do caching, prefetching, and also deal with the difference between locating a meta and locating a normal region. In general, I think having a narrow interface between different layers is necessary, as it will be easy to replace the code piece by piece in the future. > On RL, point is its API seems same as what you'd add so just reuse. That it public doesn't preclude its use internal. That the public impl is ARL, doesn't stop the ConnectionRegistry hosted impl having to be the same. As I said above, we can not introduce cyclic dependency, unless we just use the interface but use a completely different implementation when it is used in ConnectionRegistry, but is it necessary? It is confusing... To be honest, I do not fully get your point on why we need to stick on the RegionLocator interface. The implementation under the RegionLocator are all internal and private, you are free to change it at any time. So let's stop arguing on this? You can implement what you want in follow on issues, it is not a blocker problem here? Thanks. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
