Apache9 commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-641773571
> We do have 'paging' in client API; Scans (I talked of paging/iterating/cursor/scan-like API, I thought?). I mean the locating related API, for example, RegionLocator. > Here I'm advocating reuse and existing models -- e.g. RegionLocator Interface seems to have your two APIs already as you note so why wouldn't we use it instead in ConnectionRegistry? --rather than new API and new PBs. The response seems to be that its all internal so its going to be fine; sure we can make it work but if an opportunity for reuse, it could be better. I think you misunderstood the architecture. RegionLocator is part of our public client API, which can be used by end users, and it will use the package private AsyncRegionLocator in it for getting the locations, and then the AsyncRegionLocator will go to ConnectionRegistry to get the meta location. That means, RegionLocator is on the top, and ConnectionRegistry is at the bottom, we can not have a reverse dependency. > We can add prefetch to the PB to 'improve' performance but the API is still one-at-a-time; consumer has to do the juggling to figure what it should pass in as the next 'row'; instead of just next'ing to get next Region. Could you please explain more on the usage? I do not fully get the point. On locating, if you want to locate to the next region, just use the end row of the current region to locate? The prefetch is to get more locations at one time when locating(one region), so we can cache more entries at one time. ---------------------------------------------------------------- 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: [email protected]
