hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Appy (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-19356) Provide delegators and base implementation for Phoenix implemented interfaces
Date Wed, 29 Nov 2017 22:25:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-19356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16271652#comment-16271652
] 

Appy edited comment on HBASE-19356 at 11/29/17 10:24 PM:
---------------------------------------------------------

(Sorry for taking time to respond, but as simple as it looks, it's part of something very
big, and it took time to see the problem from downstream development perspective how it fits
in hbase.)

Default implementations are great, but thinking about this problem, I am beginning to think
that they don't work well with delegator pattern.
I am assuming you use delegators to wrap objects given by HBase and augment their functionality
to match your needs? If so, default impl won't help them. In fact, it might silently break
them (that's why i said above that delegates might not work well with default impl).

bq. It'd be helpful if HBase provided base implementations and delegates that Phoenix could
use instead.
My first impression was, delegates belong close to the patterns which require it. Why should
hbase provide delegates when they are not even needed inside HBase.

But looking around more: RegionScanner is LP.COPROC and all implementations are Private.
Which suggests that third-party can have their own RegionScanner impl but should have nothing
do to with internal impl. That's seems to be strong stance.
Unless users are doing something radically different, most will be just augmenting parts of
functionality to get by. Thinking about it, Phoneix is radically big, but it's still doing
that. Maybe we can have better design around this.

I am +1 to provide delegators mainly because:
- It's trivial to maintain them, and very low cost
- Makes life of CP devs easier. If someone developed a CP around some feature X, it's shouldn't
break since entirely unrelated feature Y changed. For eg. X can be extra metrics around existing
functionality, and Y can be any new feature adding anything to interface.

Let me ask what others think. If we go this way, would you be able to provide a patch [~jamestaylor]?
Please make sure to include a big class comment mentioning it's place in overall CP design,
justifying it's presence, example of how it can be used by CP, etc.

What do you say [~apurtell], [~stack], [~mdrob]?




was (Author: appy):
Default implementations are great, but thinking about this problem, I am beginning to think
that they don't work well with delegator pattern.
I am assuming you use delegators to wrap objects given by HBase and augment their functionality
to match your needs? If so, default impl won't help them. In fact, it might silently break
them (that's why i said above that delegates might not work well with default impl).

bq. It'd be helpful if HBase provided base implementations and delegates that Phoenix could
use instead.
My first impression was, delegates belong close to the patterns which require it. Why should
hbase provide delegates when they are not even needed inside HBase.

But looking around more: RegionScanner is LP.COPROC and all implementations are Private.
Which suggests that third-party can have their own RegionScanner impl but should have nothing
do to with internal impl. That's seems to be strong stance.
Unless users are doing something radically different, most will be just augmenting parts of
functionality to get by. Thinking about it, Phoneix is radically big, but it's still doing
that. Maybe we can have better design around this.

I am +1 to provide delegators mainly because:
- It's trivial to maintain them, and very low cost
- Makes life of CP devs easier. If someone developed a CP around some feature X, it's shouldn't
break since entirely unrelated feature Y changed. For eg. X can be extra metrics around existing
functionality, and Y can be any new feature adding anything to interface.

Let me ask what others think. If we go this way, would you be able to provide a patch [~jamestaylor]?
Please make sure to include a big class comment mentioning it's place in overall CP design,
justifying it's presence, example of how it can be used by CP, etc.

What do you say [~apurtell], [~stack], [~mdrob]?



> Provide delegators and base implementation for Phoenix implemented interfaces
> -----------------------------------------------------------------------------
>
>                 Key: HBASE-19356
>                 URL: https://issues.apache.org/jira/browse/HBASE-19356
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: James Taylor
>
> Many of the changes Phoenix needs to make for various branches to support different versions
of HBase are due to new methods being added to interfaces. Often times Phoenix can  use a
noop or simply needs to add the new method to it's delegate implementor. It'd be helpful if
HBase provided base implementations and delegates that Phoenix could use instead. Here are
some that come to mind:
> - RegionScanner
> - HTableInterface (Table interface now?)
> - RegionObserver
> There are likely others that [~rajeshbabu], [~ankit@apache.org], and [~elserj] would
remember.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message