You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Chia-Ping Tsai <ch...@apache.org> on 2017/09/16 11:02:00 UTC
[DISCUSS] Introduce the limited private to filter
Hi, Folks!
We have many powerful callback functions to help user to build amazing application/services. The most of functions are declared as IA.LimitedPrivate excluding the filters. As i see it, the IA.LimitedPrivate will make the improvement of filter more flexible. Also, we can introduce more server-side components to filters.
https://issues.apache.org/jira/browse/HBASE-9529 had already left the TODO "add filter limited private level" on FilterBase. I feel it is time to discuss it again.
Thanks,
Chia-Ping Tsai
Re: [DISCUSS] Introduce the limited private to filter
Posted by Chia-Ping Tsai <ch...@apache.org>.
> Are there JIRAs which are more recent that can provide more background for
> this motion ?
I'm inspired by some issues which are hindered by IA.Public of Filter. For example, 13346, 17125, 18797, and so on.
On 2017-09-16 21:09, Ted Yu <yu...@gmail.com> wrote:
> HBASE-9529 was resolved 4 years ago.
>
> Are there JIRAs which are more recent that can provide more background for
> this motion ?
>
> Cheers
>
> On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <ch...@apache.org> wrote:
>
> > Hi, Folks!
> >
> > We have many powerful callback functions to help user to build amazing
> > application/services. The most of functions are declared as
> > IA.LimitedPrivate excluding the filters. As i see it, the IA.LimitedPrivate
> > will make the improvement of filter more flexible. Also, we can introduce
> > more server-side components to filters.
> >
> > https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> > TODO "add filter limited private level" on FilterBase. I feel it is time to
> > discuss it again.
> >
> > Thanks,
> > Chia-Ping Tsai
> >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Ted Yu <yu...@gmail.com>.
HBASE-9529 was resolved 4 years ago.
Are there JIRAs which are more recent that can provide more background for
this motion ?
Cheers
On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <ch...@apache.org> wrote:
> Hi, Folks!
>
> We have many powerful callback functions to help user to build amazing
> application/services. The most of functions are declared as
> IA.LimitedPrivate excluding the filters. As i see it, the IA.LimitedPrivate
> will make the improvement of filter more flexible. Also, we can introduce
> more server-side components to filters.
>
> https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> TODO "add filter limited private level" on FilterBase. I feel it is time to
> discuss it again.
>
> Thanks,
> Chia-Ping Tsai
>
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Chia-Ping Tsai <ch...@apache.org>.
> Could we have a Filter interface that is IA.Public and contains no methods?
> Just a marker interface that gives users something they can assign to? Then
> FilterBase becomes IA.LimitedPrivate?
We can't modify Filter's API before running the proper deprecate cycle, so I prefer introducing new class to do what you suggest.
All i want to do is to separate the data and control from Filter. The former, which should be a POJO class and exposed as IA.Public, is used by normal users who apply only built-in filters and pay no attention to impl details. The latter, which is the current filters and should be exposed as IA.LimitedPrivate, work for advanced user who want to build custom filter and understand the hbase's read path.
All issues we need to address are shown below:
1) Make all filter IA.LimitedPrivate and Stable
2) Introduce POJO class(maybe call it "FilterName" or "FilterProvider") for carrying the necessary data to build a filter.
3) add the POJO calss for all built-in filter
4) Introduce setFilter(FilterName) as a replacement for setFilter(Filter) - the setFilter(Filter) will call setFilter(FilterName) internally.
For normal user in 2.0, all built-in filters work well, as usual. But they need to prepare somethings for 3.0. For example,
{code}
RowFilter filter = new RowFilter()
{code}
will be changed to
{code}
RowFilterName filter = new RowFilterName()
{code}
For advanced user in 2.0, their filters work well, as usual. But they need to implement FilterName for their filters when they deploy 3.0.
Chia-Ping
On 2017-09-21 05:26, Mike Drob <md...@apache.org> wrote:
> Could we have a Filter interface that is IA.Public and contains no methods?
> Just a marker interface that gives users something they can assign to? Then
> FilterBase becomes IA.LimitedPrivate?
>
> This might be awful for current users, I'm trying to explore in a new
> direction though.
>
>
> Mike
>
> On Wed, Sep 20, 2017 at 4:10 PM, Stack <st...@duboce.net> wrote:
>
> > I was looking at the patch on HBASE-18811
> > <https://issues.apache.org/jira/browse/HBASE-18811> to implement what has
> > since turned into this DISCUSSION.
> >
> > Get and Scan allow setting Filters.
> >
> > This means user must create them to pass in.
> >
> > If filters become LimitedPrivate, I'd imagine this will give users pause;
> > they'll ask if they should be using classes w/ this annotation.
> >
> > In refguide, it says "LimitedPrivate: used for internals we expect to be
> > pluggable, such as coprocessors" which does not provide much by way of
> > solace.
> >
> > It is as though Filter instances and their constructors should be public
> > but all else about them private. Not sure how we convey that w/ current
> > annotation vocabulary.
> >
> > Thanks,
> > M
> >
> >
> >
> > On Wed, Sep 20, 2017 at 9:41 AM, Stack <st...@duboce.net> wrote:
> >
> > > Thanks Dave for chiming in.
> > >
> > > I like the suggestion Chia-Ping of LimittedPrivate + Stable.
> > >
> > > St.Ack
> > >
> > > On Wed, Sep 20, 2017 at 6:51 AM, Dave Latham <la...@davelink.net>
> > wrote:
> > >
> > >> Thanks, Chia-Ping. I don't want to hold up improvements in HBase
> > >> internals
> > >> on behalf of Filters. Changing at major releases sounds reasonable.
> > >>
> > >> On Wed, Sep 20, 2017 at 12:32 AM, Chia-Ping Tsai <ch...@apache.org>
> > >> wrote:
> > >>
> > >> > An alternative is that we make Filter IA.LimitedPrivate and
> > >> > InterfaceStability.Stable, so we guarantee the FIlter's APIs won't be
> > >> > changed in the patch/minor release. It seems to me the changing
> > >> Filter's IA
> > >> > declaration is necessary. The filter's APIs deeply embedded in our
> > read
> > >> > path and thus the filter may hinder our improvement in given major
> > >> release
> > >> > because we have to do the proper deprecation cycle for IA.Public. I
> > >> DON'T
> > >> > want to change the Filter's APIs at the present time, but we should
> > get
> > >> > everything ready beforehand.
> > >> >
> > >> > On 2017-09-19 00:41, Dave Latham <la...@davelink.net> wrote:
> > >> > > Speaking on behalf of one HBase deployment, we do rely on custom
> > >> filters,
> > >> > > though have so far stayed away from more internal customizations
> > such
> > >> as
> > >> > > co-processors. We've gotten the sense over the years that Filters
> > >> were
> > >> > > fairly stable and seemed more reliable in that sense. I'd be sad
> > if a
> > >> > > change like this meant that more caution will need to be used in
> > >> order to
> > >> > > rely on Filters. I understand that some cleanup may need to happen
> > >> (e.g.
> > >> > > HBASE-13346) but hope that we can still be conservative in breaking
> > >> the
> > >> > > Filter apis.
> > >> > >
> > >> > > On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <
> > chia7712@apache.org>
> > >> > wrote:
> > >> > >
> > >> > > > hi stack
> > >> > > > I have filed https://issues.apache.org/jira/browse/HBASE-18811.
> > >> FYI.
> > >> > > >
> > >> > > > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> > >> > > > > It is an oversight that Filters are not annotated as
> > >> > (limited)private. We
> > >> > > > > are unable to guarantee them what public entails given their
> > >> design
> > >> > is as
> > >> > > > > yet imperfect and that they are interpolated at points subject
> > to
> > >> > change.
> > >> > > > >
> > >> > > > > +1 on taking them limited private in 2.0.0.
> > >> > > > >
> > >> > > > > Thanks for bringing this up Chia-Ping Tsai. Apt.
> > >> > > > >
> > >> > > > > St.Ack
> > >> > > > >
> > >> > > > >
> > >> > > > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <
> > >> chia7712@apache.org
> > >> > >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > > > Hi, Folks!
> > >> > > > > >
> > >> > > > > > We have many powerful callback functions to help user to build
> > >> > amazing
> > >> > > > > > application/services. The most of functions are declared as
> > >> > > > > > IA.LimitedPrivate excluding the filters. As i see it, the
> > >> > > > IA.LimitedPrivate
> > >> > > > > > will make the improvement of filter more flexible. Also, we
> > can
> > >> > > > introduce
> > >> > > > > > more server-side components to filters.
> > >> > > > > >
> > >> > > > > > https://issues.apache.org/jira/browse/HBASE-9529 had already
> > >> left
> > >> > the
> > >> > > > > > TODO "add filter limited private level" on FilterBase. I feel
> > >> it is
> > >> > > > time to
> > >> > > > > > discuss it again.
> > >> > > > > >
> > >> > > > > > Thanks,
> > >> > > > > > Chia-Ping Tsai
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Mike Drob <md...@apache.org>.
Could we have a Filter interface that is IA.Public and contains no methods?
Just a marker interface that gives users something they can assign to? Then
FilterBase becomes IA.LimitedPrivate?
This might be awful for current users, I'm trying to explore in a new
direction though.
Mike
On Wed, Sep 20, 2017 at 4:10 PM, Stack <st...@duboce.net> wrote:
> I was looking at the patch on HBASE-18811
> <https://issues.apache.org/jira/browse/HBASE-18811> to implement what has
> since turned into this DISCUSSION.
>
> Get and Scan allow setting Filters.
>
> This means user must create them to pass in.
>
> If filters become LimitedPrivate, I'd imagine this will give users pause;
> they'll ask if they should be using classes w/ this annotation.
>
> In refguide, it says "LimitedPrivate: used for internals we expect to be
> pluggable, such as coprocessors" which does not provide much by way of
> solace.
>
> It is as though Filter instances and their constructors should be public
> but all else about them private. Not sure how we convey that w/ current
> annotation vocabulary.
>
> Thanks,
> M
>
>
>
> On Wed, Sep 20, 2017 at 9:41 AM, Stack <st...@duboce.net> wrote:
>
> > Thanks Dave for chiming in.
> >
> > I like the suggestion Chia-Ping of LimittedPrivate + Stable.
> >
> > St.Ack
> >
> > On Wed, Sep 20, 2017 at 6:51 AM, Dave Latham <la...@davelink.net>
> wrote:
> >
> >> Thanks, Chia-Ping. I don't want to hold up improvements in HBase
> >> internals
> >> on behalf of Filters. Changing at major releases sounds reasonable.
> >>
> >> On Wed, Sep 20, 2017 at 12:32 AM, Chia-Ping Tsai <ch...@apache.org>
> >> wrote:
> >>
> >> > An alternative is that we make Filter IA.LimitedPrivate and
> >> > InterfaceStability.Stable, so we guarantee the FIlter's APIs won't be
> >> > changed in the patch/minor release. It seems to me the changing
> >> Filter's IA
> >> > declaration is necessary. The filter's APIs deeply embedded in our
> read
> >> > path and thus the filter may hinder our improvement in given major
> >> release
> >> > because we have to do the proper deprecation cycle for IA.Public. I
> >> DON'T
> >> > want to change the Filter's APIs at the present time, but we should
> get
> >> > everything ready beforehand.
> >> >
> >> > On 2017-09-19 00:41, Dave Latham <la...@davelink.net> wrote:
> >> > > Speaking on behalf of one HBase deployment, we do rely on custom
> >> filters,
> >> > > though have so far stayed away from more internal customizations
> such
> >> as
> >> > > co-processors. We've gotten the sense over the years that Filters
> >> were
> >> > > fairly stable and seemed more reliable in that sense. I'd be sad
> if a
> >> > > change like this meant that more caution will need to be used in
> >> order to
> >> > > rely on Filters. I understand that some cleanup may need to happen
> >> (e.g.
> >> > > HBASE-13346) but hope that we can still be conservative in breaking
> >> the
> >> > > Filter apis.
> >> > >
> >> > > On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <
> chia7712@apache.org>
> >> > wrote:
> >> > >
> >> > > > hi stack
> >> > > > I have filed https://issues.apache.org/jira/browse/HBASE-18811.
> >> FYI.
> >> > > >
> >> > > > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> >> > > > > It is an oversight that Filters are not annotated as
> >> > (limited)private. We
> >> > > > > are unable to guarantee them what public entails given their
> >> design
> >> > is as
> >> > > > > yet imperfect and that they are interpolated at points subject
> to
> >> > change.
> >> > > > >
> >> > > > > +1 on taking them limited private in 2.0.0.
> >> > > > >
> >> > > > > Thanks for bringing this up Chia-Ping Tsai. Apt.
> >> > > > >
> >> > > > > St.Ack
> >> > > > >
> >> > > > >
> >> > > > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <
> >> chia7712@apache.org
> >> > >
> >> > > > wrote:
> >> > > > >
> >> > > > > > Hi, Folks!
> >> > > > > >
> >> > > > > > We have many powerful callback functions to help user to build
> >> > amazing
> >> > > > > > application/services. The most of functions are declared as
> >> > > > > > IA.LimitedPrivate excluding the filters. As i see it, the
> >> > > > IA.LimitedPrivate
> >> > > > > > will make the improvement of filter more flexible. Also, we
> can
> >> > > > introduce
> >> > > > > > more server-side components to filters.
> >> > > > > >
> >> > > > > > https://issues.apache.org/jira/browse/HBASE-9529 had already
> >> left
> >> > the
> >> > > > > > TODO "add filter limited private level" on FilterBase. I feel
> >> it is
> >> > > > time to
> >> > > > > > discuss it again.
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Chia-Ping Tsai
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Stack <st...@duboce.net>.
I was looking at the patch on HBASE-18811
<https://issues.apache.org/jira/browse/HBASE-18811> to implement what has
since turned into this DISCUSSION.
Get and Scan allow setting Filters.
This means user must create them to pass in.
If filters become LimitedPrivate, I'd imagine this will give users pause;
they'll ask if they should be using classes w/ this annotation.
In refguide, it says "LimitedPrivate: used for internals we expect to be
pluggable, such as coprocessors" which does not provide much by way of
solace.
It is as though Filter instances and their constructors should be public
but all else about them private. Not sure how we convey that w/ current
annotation vocabulary.
Thanks,
M
On Wed, Sep 20, 2017 at 9:41 AM, Stack <st...@duboce.net> wrote:
> Thanks Dave for chiming in.
>
> I like the suggestion Chia-Ping of LimittedPrivate + Stable.
>
> St.Ack
>
> On Wed, Sep 20, 2017 at 6:51 AM, Dave Latham <la...@davelink.net> wrote:
>
>> Thanks, Chia-Ping. I don't want to hold up improvements in HBase
>> internals
>> on behalf of Filters. Changing at major releases sounds reasonable.
>>
>> On Wed, Sep 20, 2017 at 12:32 AM, Chia-Ping Tsai <ch...@apache.org>
>> wrote:
>>
>> > An alternative is that we make Filter IA.LimitedPrivate and
>> > InterfaceStability.Stable, so we guarantee the FIlter's APIs won't be
>> > changed in the patch/minor release. It seems to me the changing
>> Filter's IA
>> > declaration is necessary. The filter's APIs deeply embedded in our read
>> > path and thus the filter may hinder our improvement in given major
>> release
>> > because we have to do the proper deprecation cycle for IA.Public. I
>> DON'T
>> > want to change the Filter's APIs at the present time, but we should get
>> > everything ready beforehand.
>> >
>> > On 2017-09-19 00:41, Dave Latham <la...@davelink.net> wrote:
>> > > Speaking on behalf of one HBase deployment, we do rely on custom
>> filters,
>> > > though have so far stayed away from more internal customizations such
>> as
>> > > co-processors. We've gotten the sense over the years that Filters
>> were
>> > > fairly stable and seemed more reliable in that sense. I'd be sad if a
>> > > change like this meant that more caution will need to be used in
>> order to
>> > > rely on Filters. I understand that some cleanup may need to happen
>> (e.g.
>> > > HBASE-13346) but hope that we can still be conservative in breaking
>> the
>> > > Filter apis.
>> > >
>> > > On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <ch...@apache.org>
>> > wrote:
>> > >
>> > > > hi stack
>> > > > I have filed https://issues.apache.org/jira/browse/HBASE-18811.
>> FYI.
>> > > >
>> > > > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
>> > > > > It is an oversight that Filters are not annotated as
>> > (limited)private. We
>> > > > > are unable to guarantee them what public entails given their
>> design
>> > is as
>> > > > > yet imperfect and that they are interpolated at points subject to
>> > change.
>> > > > >
>> > > > > +1 on taking them limited private in 2.0.0.
>> > > > >
>> > > > > Thanks for bringing this up Chia-Ping Tsai. Apt.
>> > > > >
>> > > > > St.Ack
>> > > > >
>> > > > >
>> > > > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <
>> chia7712@apache.org
>> > >
>> > > > wrote:
>> > > > >
>> > > > > > Hi, Folks!
>> > > > > >
>> > > > > > We have many powerful callback functions to help user to build
>> > amazing
>> > > > > > application/services. The most of functions are declared as
>> > > > > > IA.LimitedPrivate excluding the filters. As i see it, the
>> > > > IA.LimitedPrivate
>> > > > > > will make the improvement of filter more flexible. Also, we can
>> > > > introduce
>> > > > > > more server-side components to filters.
>> > > > > >
>> > > > > > https://issues.apache.org/jira/browse/HBASE-9529 had already
>> left
>> > the
>> > > > > > TODO "add filter limited private level" on FilterBase. I feel
>> it is
>> > > > time to
>> > > > > > discuss it again.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Chia-Ping Tsai
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Stack <st...@duboce.net>.
Thanks Dave for chiming in.
I like the suggestion Chia-Ping of LimittedPrivate + Stable.
St.Ack
On Wed, Sep 20, 2017 at 6:51 AM, Dave Latham <la...@davelink.net> wrote:
> Thanks, Chia-Ping. I don't want to hold up improvements in HBase internals
> on behalf of Filters. Changing at major releases sounds reasonable.
>
> On Wed, Sep 20, 2017 at 12:32 AM, Chia-Ping Tsai <ch...@apache.org>
> wrote:
>
> > An alternative is that we make Filter IA.LimitedPrivate and
> > InterfaceStability.Stable, so we guarantee the FIlter's APIs won't be
> > changed in the patch/minor release. It seems to me the changing Filter's
> IA
> > declaration is necessary. The filter's APIs deeply embedded in our read
> > path and thus the filter may hinder our improvement in given major
> release
> > because we have to do the proper deprecation cycle for IA.Public. I DON'T
> > want to change the Filter's APIs at the present time, but we should get
> > everything ready beforehand.
> >
> > On 2017-09-19 00:41, Dave Latham <la...@davelink.net> wrote:
> > > Speaking on behalf of one HBase deployment, we do rely on custom
> filters,
> > > though have so far stayed away from more internal customizations such
> as
> > > co-processors. We've gotten the sense over the years that Filters were
> > > fairly stable and seemed more reliable in that sense. I'd be sad if a
> > > change like this meant that more caution will need to be used in order
> to
> > > rely on Filters. I understand that some cleanup may need to happen
> (e.g.
> > > HBASE-13346) but hope that we can still be conservative in breaking the
> > > Filter apis.
> > >
> > > On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <ch...@apache.org>
> > wrote:
> > >
> > > > hi stack
> > > > I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI.
> > > >
> > > > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> > > > > It is an oversight that Filters are not annotated as
> > (limited)private. We
> > > > > are unable to guarantee them what public entails given their design
> > is as
> > > > > yet imperfect and that they are interpolated at points subject to
> > change.
> > > > >
> > > > > +1 on taking them limited private in 2.0.0.
> > > > >
> > > > > Thanks for bringing this up Chia-Ping Tsai. Apt.
> > > > >
> > > > > St.Ack
> > > > >
> > > > >
> > > > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <
> chia7712@apache.org
> > >
> > > > wrote:
> > > > >
> > > > > > Hi, Folks!
> > > > > >
> > > > > > We have many powerful callback functions to help user to build
> > amazing
> > > > > > application/services. The most of functions are declared as
> > > > > > IA.LimitedPrivate excluding the filters. As i see it, the
> > > > IA.LimitedPrivate
> > > > > > will make the improvement of filter more flexible. Also, we can
> > > > introduce
> > > > > > more server-side components to filters.
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/HBASE-9529 had already
> left
> > the
> > > > > > TODO "add filter limited private level" on FilterBase. I feel it
> is
> > > > time to
> > > > > > discuss it again.
> > > > > >
> > > > > > Thanks,
> > > > > > Chia-Ping Tsai
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Dave Latham <la...@davelink.net>.
Thanks, Chia-Ping. I don't want to hold up improvements in HBase internals
on behalf of Filters. Changing at major releases sounds reasonable.
On Wed, Sep 20, 2017 at 12:32 AM, Chia-Ping Tsai <ch...@apache.org>
wrote:
> An alternative is that we make Filter IA.LimitedPrivate and
> InterfaceStability.Stable, so we guarantee the FIlter's APIs won't be
> changed in the patch/minor release. It seems to me the changing Filter's IA
> declaration is necessary. The filter's APIs deeply embedded in our read
> path and thus the filter may hinder our improvement in given major release
> because we have to do the proper deprecation cycle for IA.Public. I DON'T
> want to change the Filter's APIs at the present time, but we should get
> everything ready beforehand.
>
> On 2017-09-19 00:41, Dave Latham <la...@davelink.net> wrote:
> > Speaking on behalf of one HBase deployment, we do rely on custom filters,
> > though have so far stayed away from more internal customizations such as
> > co-processors. We've gotten the sense over the years that Filters were
> > fairly stable and seemed more reliable in that sense. I'd be sad if a
> > change like this meant that more caution will need to be used in order to
> > rely on Filters. I understand that some cleanup may need to happen (e.g.
> > HBASE-13346) but hope that we can still be conservative in breaking the
> > Filter apis.
> >
> > On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <ch...@apache.org>
> wrote:
> >
> > > hi stack
> > > I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI.
> > >
> > > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> > > > It is an oversight that Filters are not annotated as
> (limited)private. We
> > > > are unable to guarantee them what public entails given their design
> is as
> > > > yet imperfect and that they are interpolated at points subject to
> change.
> > > >
> > > > +1 on taking them limited private in 2.0.0.
> > > >
> > > > Thanks for bringing this up Chia-Ping Tsai. Apt.
> > > >
> > > > St.Ack
> > > >
> > > >
> > > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <chia7712@apache.org
> >
> > > wrote:
> > > >
> > > > > Hi, Folks!
> > > > >
> > > > > We have many powerful callback functions to help user to build
> amazing
> > > > > application/services. The most of functions are declared as
> > > > > IA.LimitedPrivate excluding the filters. As i see it, the
> > > IA.LimitedPrivate
> > > > > will make the improvement of filter more flexible. Also, we can
> > > introduce
> > > > > more server-side components to filters.
> > > > >
> > > > > https://issues.apache.org/jira/browse/HBASE-9529 had already left
> the
> > > > > TODO "add filter limited private level" on FilterBase. I feel it is
> > > time to
> > > > > discuss it again.
> > > > >
> > > > > Thanks,
> > > > > Chia-Ping Tsai
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Chia-Ping Tsai <ch...@apache.org>.
An alternative is that we make Filter IA.LimitedPrivate and InterfaceStability.Stable, so we guarantee the FIlter's APIs won't be changed in the patch/minor release. It seems to me the changing Filter's IA declaration is necessary. The filter's APIs deeply embedded in our read path and thus the filter may hinder our improvement in given major release because we have to do the proper deprecation cycle for IA.Public. I DON'T want to change the Filter's APIs at the present time, but we should get everything ready beforehand.
On 2017-09-19 00:41, Dave Latham <la...@davelink.net> wrote:
> Speaking on behalf of one HBase deployment, we do rely on custom filters,
> though have so far stayed away from more internal customizations such as
> co-processors. We've gotten the sense over the years that Filters were
> fairly stable and seemed more reliable in that sense. I'd be sad if a
> change like this meant that more caution will need to be used in order to
> rely on Filters. I understand that some cleanup may need to happen (e.g.
> HBASE-13346) but hope that we can still be conservative in breaking the
> Filter apis.
>
> On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <ch...@apache.org> wrote:
>
> > hi stack
> > I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI.
> >
> > On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> > > It is an oversight that Filters are not annotated as (limited)private. We
> > > are unable to guarantee them what public entails given their design is as
> > > yet imperfect and that they are interpolated at points subject to change.
> > >
> > > +1 on taking them limited private in 2.0.0.
> > >
> > > Thanks for bringing this up Chia-Ping Tsai. Apt.
> > >
> > > St.Ack
> > >
> > >
> > > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <ch...@apache.org>
> > wrote:
> > >
> > > > Hi, Folks!
> > > >
> > > > We have many powerful callback functions to help user to build amazing
> > > > application/services. The most of functions are declared as
> > > > IA.LimitedPrivate excluding the filters. As i see it, the
> > IA.LimitedPrivate
> > > > will make the improvement of filter more flexible. Also, we can
> > introduce
> > > > more server-side components to filters.
> > > >
> > > > https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> > > > TODO "add filter limited private level" on FilterBase. I feel it is
> > time to
> > > > discuss it again.
> > > >
> > > > Thanks,
> > > > Chia-Ping Tsai
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Dave Latham <la...@davelink.net>.
Speaking on behalf of one HBase deployment, we do rely on custom filters,
though have so far stayed away from more internal customizations such as
co-processors. We've gotten the sense over the years that Filters were
fairly stable and seemed more reliable in that sense. I'd be sad if a
change like this meant that more caution will need to be used in order to
rely on Filters. I understand that some cleanup may need to happen (e.g.
HBASE-13346) but hope that we can still be conservative in breaking the
Filter apis.
On Sat, Sep 16, 2017 at 7:27 PM, Chia-Ping Tsai <ch...@apache.org> wrote:
> hi stack
> I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI.
>
> On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> > It is an oversight that Filters are not annotated as (limited)private. We
> > are unable to guarantee them what public entails given their design is as
> > yet imperfect and that they are interpolated at points subject to change.
> >
> > +1 on taking them limited private in 2.0.0.
> >
> > Thanks for bringing this up Chia-Ping Tsai. Apt.
> >
> > St.Ack
> >
> >
> > On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <ch...@apache.org>
> wrote:
> >
> > > Hi, Folks!
> > >
> > > We have many powerful callback functions to help user to build amazing
> > > application/services. The most of functions are declared as
> > > IA.LimitedPrivate excluding the filters. As i see it, the
> IA.LimitedPrivate
> > > will make the improvement of filter more flexible. Also, we can
> introduce
> > > more server-side components to filters.
> > >
> > > https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> > > TODO "add filter limited private level" on FilterBase. I feel it is
> time to
> > > discuss it again.
> > >
> > > Thanks,
> > > Chia-Ping Tsai
> > >
> > >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Chia-Ping Tsai <ch...@apache.org>.
hi stack
I have filed https://issues.apache.org/jira/browse/HBASE-18811. FYI.
On 2017-09-17 05:31, Stack <st...@duboce.net> wrote:
> It is an oversight that Filters are not annotated as (limited)private. We
> are unable to guarantee them what public entails given their design is as
> yet imperfect and that they are interpolated at points subject to change.
>
> +1 on taking them limited private in 2.0.0.
>
> Thanks for bringing this up Chia-Ping Tsai. Apt.
>
> St.Ack
>
>
> On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <ch...@apache.org> wrote:
>
> > Hi, Folks!
> >
> > We have many powerful callback functions to help user to build amazing
> > application/services. The most of functions are declared as
> > IA.LimitedPrivate excluding the filters. As i see it, the IA.LimitedPrivate
> > will make the improvement of filter more flexible. Also, we can introduce
> > more server-side components to filters.
> >
> > https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> > TODO "add filter limited private level" on FilterBase. I feel it is time to
> > discuss it again.
> >
> > Thanks,
> > Chia-Ping Tsai
> >
> >
>
Re: [DISCUSS] Introduce the limited private to filter
Posted by Stack <st...@duboce.net>.
It is an oversight that Filters are not annotated as (limited)private. We
are unable to guarantee them what public entails given their design is as
yet imperfect and that they are interpolated at points subject to change.
+1 on taking them limited private in 2.0.0.
Thanks for bringing this up Chia-Ping Tsai. Apt.
St.Ack
On Sat, Sep 16, 2017 at 4:02 AM, Chia-Ping Tsai <ch...@apache.org> wrote:
> Hi, Folks!
>
> We have many powerful callback functions to help user to build amazing
> application/services. The most of functions are declared as
> IA.LimitedPrivate excluding the filters. As i see it, the IA.LimitedPrivate
> will make the improvement of filter more flexible. Also, we can introduce
> more server-side components to filters.
>
> https://issues.apache.org/jira/browse/HBASE-9529 had already left the
> TODO "add filter limited private level" on FilterBase. I feel it is time to
> discuss it again.
>
> Thanks,
> Chia-Ping Tsai
>
>