hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-14944) Minimize or eliminate source incompatible changes due to HBASE-14605, HBASE-14631, and HBASE-14655
Date Mon, 07 Dec 2015 22:01:11 GMT

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

Andrew Purtell edited comment on HBASE-14944 at 12/7/15 10:00 PM:
------------------------------------------------------------------

For SplitTransaction and RegionMergeTransaction we could add add new methods getRequestUser
and setRequestUser for accessing the request user (and setting it), but this leaves us with
the same problem, new abstract methods, because these are both interfaces.

For the compaction related changes to Store we can carry around the request User within CompactionContext
and CompactionRequest. CompactionContext is private. CompactionRequest is LP(Coprocessor).
Both are abstract classes so by providing implementations of getters and setters we won't
cause source or binary compat problems. We would however introduce new methods so any users
of same in code written against new release N would not compile after rollback to N-1.

Any other ideas [~ndimiduk], [~ted_yu] ?

Also for sake of completeness, we have the option of reverting the chain of commits leading
to this point back to the original security bug fix for secure bulk load, and advise in the
troubleshooting section of the manual and/or release notes that we can't fix the problem in
1.0 or 1.1.


was (Author: apurtell):
For SplitTransaction and RegionMergeTransaction we could add add new methods getRequestUser
and setRequestUser for accessing the request user (and setting it), but this leaves us with
the same problem, new abstract methods, because these are both interfaces.

For the compaction related changes to Store we can carry around the request User within CompactionContext
and CompactionRequest. CompactionContext is private. CompactionRequest is LP(Coprocessor).
Both are abstract classes so by providing implementations of getters and setters we won't
cause source or binary compat problems. We would however introduce changes where code written
against new release N won't compile after rollback to N-1. 

Any other ideas [~ndimiduk], [~ted_yu] ?

Also for sake of completeness, we have the option of reverting the chain of commits leading
to this point back to the original security bug fix for secure bulk load, and advise in the
troubleshooting section of the manual and/or release notes that we can't fix the problem in
1.0 or 1.1.

> Minimize or eliminate source incompatible changes due to HBASE-14605, HBASE-14631, and
HBASE-14655
> --------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-14944
>                 URL: https://issues.apache.org/jira/browse/HBASE-14944
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Andrew Purtell
>            Priority: Blocker
>             Fix For: 1.1.3, 1.0.4
>
>
> Minimize or eliminate source incompatible changes due to HBASE-14605, HBASE-14631, and
HBASE-14655. The changes are due to abstract method additions to carry the correct (not current)
{{User}} through to where authoritative decisions or audit is performed.
> HBASE-14605 introduces source incompatible changes to the SplitTransaction interface:
> - Adds abstract method execute(Server, RegionServerServices, User)
> - Adds abstract method rollback(Server, RegionServerServices, User)
> HBASE-14631 introduces source incompatible changes to the RegionMergeTransaction interface:
> - Adds abstract method execute(Server, RegionServerServices, User)
> - Adds abstract method rollback(Server, RegionServerServices, User)
> HBASE-14655 introduces source incompatible changes to the Store interface:
> - Adds abstract method compact(CompactionContext, CompactionThroughputController, User)
> - Adds abstract method requestCompaction( int, CompactionRequest, User)
> Default implementations are provided for binary compatibility but implementors of these
interface won't recompile until implementations of the new methods are added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message