Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E0F11FE72 for ; Thu, 18 Apr 2013 19:30:13 +0000 (UTC) Received: (qmail 99984 invoked by uid 500); 18 Apr 2013 19:30:13 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 99929 invoked by uid 500); 18 Apr 2013 19:30:13 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 99920 invoked by uid 99); 18 Apr 2013 19:30:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Apr 2013 19:30:13 +0000 Date: Thu, 18 Apr 2013 19:30:13 +0000 (UTC) From: "John Vines (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Assigned] (ACCUMULO-571) Merge table into existing table 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/ACCUMULO-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Vines reassigned ACCUMULO-571: ----------------------------------- Assignee: (was: John Vines) > Merge table into existing table > ------------------------------- > > Key: ACCUMULO-571 > URL: https://issues.apache.org/jira/browse/ACCUMULO-571 > Project: Accumulo > Issue Type: New Feature > Components: client, tserver > Reporter: John Vines > Labels: gsoc2013, mentor > > This is idea that was recently brought to my attention. The use case is a user wants to essentially clone a subset of a table into an existing table. Currently cloning does not allow this. Current option is to copy the files in hdfs and then bulk import, since bulk import moves the files. This is pretty wasteful. Under the hood, the system can handle the cross-linking between files like that. We just need a mechanism to provide the ability to assign a subset of data to another region. > Potential uses include the above mentioned, as well as the potential for users to bring fresh data into a table which was cloned and modified. There may be other cases, but I haven't fully thought out this problem space. > The biggest problem with this is it does put the onus on the user for ensuring that data in the in memory maps is flushed before moving, as well as for handling the possibility of duplicate data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira