Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 18 Jul 2016 17:06:20 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12989123.1468417864000.61006.1468861580723@Atlassian.JIRA>
In-Reply-To: <JIRA.12989123.1468417864000@Atlassian.JIRA>
References: <JIRA.12989123.1468417864000@Atlassian.JIRA> <JIRA.12989123.1468417864653@arcas>
Subject: [jira] [Commented] (HBASE-16225) Refactor ScanQueryMatcher
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 18 Jul 2016 17:06:22 -0000


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

stack commented on HBASE-16225:
-------------------------------

[~jingcheng.du@intel.com] Maybe we should move this discussion over to HBASE-9440 now we know the issue for this (thanks [~lhofhansl]). Can you say more why the block approach wouldn't work? Because we are reading from a single heap only most of the time? Thanks J.

> Refactor ScanQueryMatcher
> -------------------------
>
>                 Key: HBASE-16225
>                 URL: https://issues.apache.org/jira/browse/HBASE-16225
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Duo Zhang
>
> As said in HBASE-16223, the code of {{ScanQueryMatcher}} is too complicated. I suggest that we can abstract an interface and implement several sub classes which separate different logic into different implementations. For example, the requirements of compaction and user scan are different, now we also need to consider the logic of user scan even if we only want to add a logic for compaction. And at least, the raw scan does not need a query matcher... we can implement a dummy query matcher for it.
> Suggestions are welcomed. Thanks.


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