Cool, thanks James. It looks like our Abhishek is thinking along these
lines too, see HBASE-18127.
On Sun, Jul 30, 2017 at 1:07 PM, James Taylor
wrote:
> Thanks for writing this up, Andy. In the spirit of this, I've
> filed HBASE-18482.
>
> On Wed, Jul 26, 2017 at 6:59 PM, Anoop John wrote:
>
>
Thanks for writing this up, Andy. In the spirit of this, I've
filed HBASE-18482.
On Wed, Jul 26, 2017 at 6:59 PM, Anoop John wrote:
> Well said Andy. Big +1
>
> -Anoop-
>
> On Wed, Jul 26, 2017 at 2:52 AM, Josh Elser wrote:
> > Thanks for the reply!
> >
> > On 7/24/17 9:52 PM, Andrew Purtell w
Well said Andy. Big +1
-Anoop-
On Wed, Jul 26, 2017 at 2:52 AM, Josh Elser wrote:
> Thanks for the reply!
>
> On 7/24/17 9:52 PM, Andrew Purtell wrote:
>>
>> As a coprocessor application there is no way not to be bogged down in
>> internal details. Coprocessors are by definition mixin extension
Thanks for the reply!
On 7/24/17 9:52 PM, Andrew Purtell wrote:
As a coprocessor application there is no way not to be bogged down in
internal details. Coprocessors are by definition mixin extensions to
internal HBase code. Compatibility discontinuities are going to be a fact
of life. All copro
As a coprocessor application there is no way not to be bogged down in
internal details. Coprocessors are by definition mixin extensions to
internal HBase code. Compatibility discontinuities are going to be a fact
of life. All coprocessor APIs are LimitedPrivate. This is weaker than
Public. I don't
Hi all,
James raised a good question on PHOENIX-3598 surrounding how Phoenix
should handle the case when a specific version of HBase that Phoenix
uses is lacking/missing some kind of code/functionality.
For example, I wrote some test cases which set-up a minicluster with
Kerberos. HBase 0.98
