Forgot to mention, there was some discussion about filter / coprocessors versus plugins. It seems that coprocessors are doing both more user-facing database trigger kind of functionality + some plugging into Hbase internals functionality. I think longer term, we should define different interfaces for some pluggable functionality (see recent StorageEngine, Compaction, Flush, HLog, etc) and keep coprocessors more simple. This was plugins would be the supported way to extend HBase, and the interfaces would be more stable.
On Mon, Feb 10, 2014 at 2:23 PM, Enis Söztutar <[email protected]> wrote: > Awesome work Jeffrey. > > Should we name the branch 4.0, instead of 4.0.0? > > It would be good to have a list of methods used by Phoenix to be > identified and tagged in HBase so that at least future changes are not > completely random. We might start with annotation > InterfaceAudience.LimitedPrivate, so that HBase devs will be more careful. > However, we should also try to make Phoenix not so far-reaching into HBase > internals as well. > > Enis > > > On Mon, Feb 10, 2014 at 2:16 PM, Andrew Purtell <[email protected]>wrote: > >> On Mon, Feb 10, 2014 at 2:07 PM, James Taylor <[email protected] >> >wrote: >> >> > Mujtaba - would it be >> > feasible to setup Jenkins builds for this branch as well? >> > >> >> Or, HBase 0.98 is really close to HBase trunk still. If you set up a job >> building against HBase trunk snapshots (and HBase remembers to publish >> those...) then Jenkins can catch any incompatibilities accidentally >> introduced going forward. >> >> -- >> Best regards, >> >> - Andy >> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> (via Tom White) >> > >
