Great. Thanks James. On Sunday, May 18, 2014, James Taylor <jtay...@salesforce.com> wrote:
> Phoenix doesn't actually do anything particularly fancy with the > RegionServer interface. We typically just run the scan internally and > return a different scanner (over the aggregated or topN results). > > We'd be happy to act as the "guinea pig" for this new, simpler coprocessor > API. > > Thanks, > James > > > On Sun, May 18, 2014 at 12:41 AM, Andrew Purtell > <apurt...@apache.org<javascript:;> > >wrote: > > > 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 <la...@apache.org <javascript:;>> > 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 <jtay...@salesforce.com <javascript:;><javascript:;>> > > > To: "dev@hbase.apache.org <javascript:;> <javascript:;>" < > dev@hbase.apache.org <javascript:;> > > <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 > > > <apurt...@apache.org<javascript:;> > > <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) > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
