Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C719B18A8F for ; Fri, 13 Nov 2015 00:29:11 +0000 (UTC) Received: (qmail 99737 invoked by uid 500); 13 Nov 2015 00:29:11 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 99690 invoked by uid 500); 13 Nov 2015 00:29:11 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 99588 invoked by uid 99); 13 Nov 2015 00:29:11 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Nov 2015 00:29:11 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 4B4252C1F7C for ; Fri, 13 Nov 2015 00:29:11 +0000 (UTC) Date: Fri, 13 Nov 2015 00:29:11 +0000 (UTC) From: "Hadoop QA (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-14355) Scan different TimeRange for each column family MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003284#comment-15003284 ] Hadoop QA commented on HBASE-14355: ----------------------------------- {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12772054/HBASE-14355.branch-1.patch against branch-1 branch at commit 789f8a5a70242c16ce10bc95401c51c7d04debfa. ATTACHMENT ID: 12772054 {color:green}+1 @author{color}. The patch does not contain any @author tags. {color:green}+1 tests included{color}. The patch appears to include 12 new or modified tests. {color:green}+1 hadoop versions{color}. The patch compiles with all supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.6.1 2.7.0 2.7.1) {color:green}+1 javac{color}. The applied patch does not increase the total number of javac compiler warnings. {color:green}+1 protoc{color}. The applied patch does not increase the total number of protoc compiler warnings. {color:green}+1 javadoc{color}. The javadoc tool did not generate any warning messages. {color:red}-1 checkstyle{color}. The applied patch generated 3774 checkstyle errors (more than the master's current 3773 errors). {color:green}+1 findbugs{color}. The patch does not introduce any new Findbugs (version 2.0.3) warnings. {color:green}+1 release audit{color}. The applied patch does not increase the total number of release audit warnings. {color:red}-1 lineLengths{color}. The patch introduces the following lines longer than 100: + "ualifier\030\002 \003(\014\"\271\003\n\003Get\022\013\n\003row\030\001 \002(\014\022 \n\006c" + + "ount\030\002 \001(\005\022\016\n\006exists\030\003 \001(\010\022\024\n\005stale\030\004 \001(" + + "l\022\013\n\003row\030\001 \002(\014\022\024\n\014service_name\030\002 \002(\t\022\023\n\013" + + new java.lang.String[] { "Row", "Column", "Attribute", "Filter", "TimeRange", "MaxVersions", "CacheBlocks", "StoreLimit", "StoreOffset", "ExistenceOnly", "ClosestRowBefore", "Consistency", "CfTimeRange", }); + new java.lang.String[] { "Column", "Attribute", "StartRow", "StopRow", "Filter", "TimeRange", "MaxVersions", "CacheBlocks", "BatchSize", "MaxResultSize", "StoreLimit", "StoreOffset", "LoadColumnFamiliesOnDemand", "Small", "Reversed", "Consistency", "Caching", "AllowPartialResults", "CfTimeRange", }); {color:green}+1 site{color}. The mvn post-site goal succeeds with this patch. {color:green}+1 core tests{color}. The patch passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/16502//testReport/ Release Findbugs (version 2.0.3) warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/16502//artifact/patchprocess/newFindbugsWarnings.html Checkstyle Errors: https://builds.apache.org/job/PreCommit-HBASE-Build/16502//artifact/patchprocess/checkstyle-aggregate.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/16502//console This message is automatically generated. > Scan different TimeRange for each column family > ----------------------------------------------- > > Key: HBASE-14355 > URL: https://issues.apache.org/jira/browse/HBASE-14355 > Project: HBase > Issue Type: New Feature > Components: Client, regionserver, Scanners > Reporter: Dave Latham > Assignee: churro morales > Fix For: 2.0.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14355-v1.patch, HBASE-14355-v10.patch, HBASE-14355-v11.patch, HBASE-14355-v2.patch, HBASE-14355-v3.patch, HBASE-14355-v4.patch, HBASE-14355-v5.patch, HBASE-14355-v6.patch, HBASE-14355-v7.patch, HBASE-14355-v8.patch, HBASE-14355-v9.patch, HBASE-14355.branch-1.patch, HBASE-14355.patch > > > At present the Scan API supports only table level time range. We have specific use cases that will benefit from per column family time range. (See background discussion at https://mail-archives.apache.org/mod_mbox/hbase-user/201508.mbox/%3CCAA4mzom00ef5eoXStK0HEtxebY8mQSs61GBVGttgpASpmhQHaw@mail.gmail.com%3E) > There are a couple of choices that would be good to validate. First - how to update the Scan API to support family and table level updates. One proposal would be to add Scan.setTimeRange(byte family, long minTime, long maxTime), then store it in a Map. When executing the scan, if a family has a specified TimeRange, then use it, otherwise fall back to using the table level TimeRange. Clients using the new API against old region servers would not get the families correctly filterd. Old clients sending scans to new region servers would work correctly. > The other question is how to get StoreFileScanner.shouldUseScanner to match up the proper family and time range. It has the Scan available but doesn't currently have available which family it is a part of. One option would be to try to pass down the column family in each constructor path. Another would be to instead alter shouldUseScanner to pass down the specific TimeRange to use (similar to how it currently passes down the columns to use which also appears to be a workaround for not having the family available). -- This message was sent by Atlassian JIRA (v6.3.4#6332)