Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 7 Oct 2013 22:53:41 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12671498.1380599103332.28623.1381186421822@arcas>
In-Reply-To: <JIRA.12671498.1380599103332@arcas>
References: <JIRA.12671498.1380599103332@arcas>
Subject: [jira] [Resolved] (ACCUMULO-1744) A "smarter" merge command
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ACCUMULO-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Elser resolved ACCUMULO-1744.
----------------------------------

    Resolution: Invalid

Yup, you're right [~kturner]. I had no idea that option existed.

> A "smarter" merge command
> -------------------------
>
>                 Key: ACCUMULO-1744
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1744
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: shell
>            Reporter: Josh Elser
>             Fix For: 1.7.0
>
>
> The `merge` shell command is a nice little feature that helps undo bad partitioning of a table due to a variety of reasons (too many splits added, too small of a split threshold).
> The way that `merge` actually works isn't very user friendly as it forces the user to manually chain invocations of `merge` together to "implement" the semantics they really want of merge into N tablets or merge into tablets of size no more than X.
> Given that we have all of the information stored in {{!METADATA}} to atuomatically compute this, it seems like a straightforward command that we could provide, whether as different options on the existing `merge` command or as a new command.


--
This message was sent by Atlassian JIRA
(v6.1#6144)