You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by "Keith Turner (JIRA)" <ji...@apache.org> on 2012/05/23 22:43:43 UTC

[jira] [Comment Edited] (ACCUMULO-420) Allow per compaction iterator settings

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

Keith Turner edited comment on ACCUMULO-420 at 5/23/12 8:43 PM:
----------------------------------------------------------------

Adding this to the API should be fairly simple.  Thinking of simply adding the following to TableOperations 

{code}
  public void compact(String tableName, Text start, Text end, List<IteratorSettings> iterators, boolean flush, boolean wait)
{code}

However making this functionality available from the shell does not seem so simple.  Billie and I discussed this today and came up with some initial thoughts, but did not decide on anything.

 * Allow arguments to the compact command like <prio>=<iterclass>{ <prio>=<iterclass>).  For each iterator argument given to the compact command it would then prompt you for options.  This does not seem great for writing scripts that initiate compactions.
 * Repurpose the setscaniter command to allow creating an iterator profile in the shell.  Then a scan or compact command could reference this iterator profile.  This way iterators configured on the shell are only used if explicitly requested.  This also does not seem great for scripting compactions.
 * Compact command could take an argument that is a complex expression that encapsulates iterators and their options.   This is great for scripting but not so good for interactive use.  The complex expression could be encoded in json.  This makes it a bit less onerous, because a well known encoding format is used.  However with json users would still need to know the label names and expected structure.  Could give an example of this in the help to make it easier.

 
                
      was (Author: kturner):
    Adding this to the API should be fairly simple.  Thinking of simply adding the following to TableOperations 

{code}
  public void compact(String tableName, Text start, Text end, List<IteratorSettings> iterators, boolean flush, boolean wait)
{code}

However making this functionality available from the shell does not seem so simple.  Billie and I discussed this today and came up with some initial thoughts, but did not decide on anything.

 * Allow arguments to the compact command like <prio>=<iterclass>{ <prio>=<iterclass>).  For each iterator argument given to the compact command it would then prompt you for options.  This does not seem great for writing scripts that initiate compactions.
 * Repurpose the setscaniter command to allow creating an iterator profile in the shell.  Then a scan or compact command could reference this iterator profile.  This way iterators configured on the shell are only used if explicitly requested.  This also does not seem great for scripting compactions.
 * Compact command could take an argument that is a complex expression that encapsulates iterators and their options.   This is great for scripting but not so good for interactive use.  

 
                  
> Allow per compaction iterator settings
> --------------------------------------
>
>                 Key: ACCUMULO-420
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-420
>             Project: Accumulo
>          Issue Type: New Feature
>            Reporter: Keith Turner
>            Assignee: Sapan Shah
>             Fix For: 1.5.0
>
>
> It may be useful to allow the compact command to specify an iterator to be used for that compaction.  For example if someone wanted to apply a filter once to a table, they could force a compaction with that filter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira