hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: On coprocessor API evolution
Date Sun, 18 May 2014 07:41:42 GMT
That's a good point. We have use cases for the current APIs (security,
Phoenix) but no motivating use case for HBASE-11125 yet. I would be better
if we had one lined up.


On Sunday, May 18, 2014, lars hofhansl <larsh@apache.org> wrote:

> But note that such a high level interface will probably not allow access
> at level necessary for Phoenix.
> You can't eat your cake and keep it. For some performance you deep access
> to HBase internals (RegionScanners, for example). At the same time, these
> *are* internal.
>
>
> I suppose to least we can do is marking these interfaces/classes clearly
> (as we have started in 0.96 and later as being public/private/evolving,
> etc).
>
> There's a use case for HBASE-11125, but to me at least it does not seem to
> be Phoenix. But maybe I am wrong.
>
>
> -- Lars
>
>
>
> ________________________________
>  From: James Taylor <jtaylor@salesforce.com <javascript:;>>
> To: "dev@hbase.apache.org <javascript:;>" <dev@hbase.apache.org<javascript:;>
> >
> Sent: Thursday, May 15, 2014 6:47 PM
> Subject: Re: On coprocessor API evolution
>
>
> +1 to HBASE-11125. Current incarnation of coprocessors expose too much of
> the guts of the implementation.
>
>
>
> On Wed, May 14, 2014 at 6:13 PM, Andrew Purtell <apurtell@apache.org<javascript:;>>
> wrote:
>
> > Because coprocessor APIs are so tightly bound with internals, if we apply
> > suggested rules like as mentioned on HBASE-11054:
> >
> >       I'd say policy should be no changes to method apis across minor
> > versions
> >
> > This will lock coprocessor based components to the limitations of the API
> > as we encounter them. Core code does not suffer this limitation, we are
> > otherwise free to refactor and change internal methods. For example, if
> we
> > apply this policy to the 0.98 branch, then we will have to abandon
> further
> > security feature development there and move to trunk only. This is
> because
> > we already are aware that coprocessor APIs as they stand are insufficient
> > still.
> >
> > Coprocessor APIs are a special class of internal method. We have had a
> > tension between allowing freedom of movement for developing them out and
> > providing some measure of stability for implementors for a while.
> >
> > It is my belief that the way forward is something like HBASE-11125.
> Perhaps
> > we can take this discussion to that JIRA and have this long overdue
> > conversation.
> >
> > Regarding security features specifically, I would also like to call your
> > attention to HBASE-11127. I think security has been an optional feature
> > long enough, it is becoming a core requirement for the project, so should
> > be moved into core. Sure, we can therefore sidestep any issues with
> > coprocessor API sufficiency for hosting security features. However, in my
> > opinion we should pursue both HBASE-11125 and HBASE-11127; the first to
> > provide the relative stability long asked for by coprocessor API users,
> the
> > latter to cleanly solve emerging issues with concurrency and versioning.
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message