[
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
