Scan API Improvements - HBASE-13441

[Jonathan Lawlor <jo...@cloudera.com>]

Hey all,

Recently there have been a bunch of nice changes in Scanners, and in that
spirit, it may be a good time to discuss potential improvements to the
public Scan API that could be made in 2.0.0+. Currently there is an
umbrella issue open (HBASE-13441) with a couple of proposed changes.

Seems like a bunch of APIs could be deprecated (or perhaps repurposed as
"expert"). Deprecating these APIs would be useful as it would allow us to
make nice optimizations server side in the future. For example, removing
caching and max result size from the Scan API would allow these parameters
to be tuned by the server based on the RPC pipeline. Such control seems out
of place in the Scan API (seems more appropriate to give the server control
over these parameters). There are also some APIs that could use some love
in terms of doc improvements.

If anyone has some time to take a look it would be great to get some
opinions/ideas.

Thanks!
Jonathan

Re: Scan API Improvements - HBASE-13441

[Anoop John <an...@gmail.com>]

+1 for the cleanup either by deprecate or Java doc improvement.  Expecting
patches under the Umbrella Jira.

-Anoop-

On Wed, Apr 29, 2015 at 10:10 PM, Stack <st...@duboce.net> wrote:

> On Tue, Apr 28, 2015 at 4:43 PM, Jonathan Lawlor <
> jonathan.lawlor@cloudera.com> wrote:
>
> > Hey all,
> >
> > Recently there have been a bunch of nice changes in Scanners, and in that
> > spirit, it may be a good time to discuss potential improvements to the
> > public Scan API that could be made in 2.0.0+. Currently there is an
> > umbrella issue open (HBASE-13441) with a couple of proposed changes.
> >
> > Seems like a bunch of APIs could be deprecated (or perhaps repurposed as
> > "expert"). Deprecating these APIs would be useful as it would allow us to
> > make nice optimizations server side in the future. For example, removing
> > caching and max result size from the Scan API would allow these
> parameters
> > to be tuned by the server based on the RPC pipeline. Such control seems
> out
> > of place in the Scan API (seems more appropriate to give the server
> control
> > over these parameters). There are also some APIs that could use some love
> > in terms of doc improvements.
> >
> > If anyone has some time to take a look it would be great to get some
> > opinions/ideas.
> >
>
> Nice writeup. +1 on deprecating APIs that no longer make sense after Scan
> underwent an overhaul.
> St.Ack
>

Re: Scan API Improvements - HBASE-13441

[Stack <st...@duboce.net>]

On Tue, Apr 28, 2015 at 4:43 PM, Jonathan Lawlor <
jonathan.lawlor@cloudera.com> wrote:

> Hey all,
>
> Recently there have been a bunch of nice changes in Scanners, and in that
> spirit, it may be a good time to discuss potential improvements to the
> public Scan API that could be made in 2.0.0+. Currently there is an
> umbrella issue open (HBASE-13441) with a couple of proposed changes.
>
> Seems like a bunch of APIs could be deprecated (or perhaps repurposed as
> "expert"). Deprecating these APIs would be useful as it would allow us to
> make nice optimizations server side in the future. For example, removing
> caching and max result size from the Scan API would allow these parameters
> to be tuned by the server based on the RPC pipeline. Such control seems out
> of place in the Scan API (seems more appropriate to give the server control
> over these parameters). There are also some APIs that could use some love
> in terms of doc improvements.
>
> If anyone has some time to take a look it would be great to get some
> opinions/ideas.
>

Nice writeup. +1 on deprecating APIs that no longer make sense after Scan
underwent an overhaul.
St.Ack