hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17730) Migration to 2.0 for coprocessors
Date Mon, 06 Mar 2017 06:01:32 GMT

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

Anoop Sam John commented on HBASE-17730:

Some of CP API changes did for 2.0, we kept in BC way to assure compatibility.  Now as any
way it is broken, may be we can ease things and break the compatibility there also.   Similar
way what abt Filters?  Those also possible to break BC for 2.0?

> Migration to 2.0 for coprocessors 
> ----------------------------------
>                 Key: HBASE-17730
>                 URL: https://issues.apache.org/jira/browse/HBASE-17730
>             Project: HBase
>          Issue Type: Sub-task
>          Components: migration
>            Reporter: Appy
>             Fix For: 2.0.0
> Jiras breaking coprocessor compatibility should be marked with component ' Coprocessor',
and label 'incompatible'.
> Close to releasing 2.0, we should go through all such jiras and write down steps for
migrating coprocessor easily.
> The idea is, it might be very hard to fix coprocessor breakages by reverse engineering
errors,  but will be easier we suggest easiest way to fix breakages resulting from each individual
incompatible change.
> For eg. HBASE-17312 is incompatible change. It'll result in 100s of errors because BaseXXXObserver
classes are gone and will probably result in a lot of confusion, but if we explicitly mention
the fix which is just one line change - replace "Foo extends BaseXXXObserver" with "Foo implements
XXXObserver" - it makes it very easy.

This message was sent by Atlassian JIRA

View raw message