Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 16 Oct 2014 20:38:35 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12748384.1413400650000.281268.1413491915074@Atlassian.JIRA>
In-Reply-To: <JIRA.12748384.1413400650000@Atlassian.JIRA>
References: <JIRA.12748384.1413400650000@Atlassian.JIRA>
 <JIRA.12748384.1413400650044@arcas>
Subject: [jira] [Commented] (ACCUMULO-3236) Clone table into an existing
 table
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Christopher Tubbs commented on ACCUMULO-3236:
---------------------------------------------

Oh, I see. Okay, so you've convinced me that your proposal supports more use cases than mine. Although I prefer the more standard semantics, I agree with the goal of supporting a broader range of use cases.

I'm still concerned about the API semantics, because I think "clone" is the wrong verb to convey and will be prone to confusion. Maybe "cloneInto" would work. Otherwise, "inject", "insert", "importFrom", or something else.

> Clone table into an existing table
> ----------------------------------
>
>                 Key: ACCUMULO-3236
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3236
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client, tserver
>            Reporter: John Vines
>             Fix For: 1.7.0
>
>
> Currently we have the ability to clone a table, which takes all files belonging to an existing table and then makes them owned by a second, brand new table. I think there is a logic extension to this where you can add the files to an already existing table.
> One point of concern is if data is unused in existing files due to major compactions of the shared files in the source table. This can be mitigated by either chopping the files (which sorta goes against the idea of cloning) or ensuring that at source table splits exist in the destination table.


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