Currently the org.apache.accumulo.core.util.shell.commands.SetIterCommand
requires that the iterator implement the OptionDescriber interface (line
128). This prevents using some useful iterators at the shell, for instance
the DebugIterator. A nice way to learn how iterators work is to set this
iterator, use "debug on" at the shell and start scanning different ways.

There are two possible solutions that I see. One is to make all iterators
delivered with Accumulo implement OptionDescriber, and document this shell
quirk, or to use reflection in the shell code to see if the iterator class
implements OptionDescriber, otherwise just ensure it implements
SortedKeyValueIterator.

ACCUMULO-129

https://issues.apache.org/jira/browse/ACCUMULO-129

On Tue, Nov 8, 2011 at 3:05 PM, Jim Klucar <[EMAIL PROTECTED]> wrote:

> Currently the org.apache.accumulo.core.util.shell.commands.SetIterCommand
> requires that the iterator implement the OptionDescriber interface (line
> 128). This prevents using some useful iterators at the shell, for instance
> the DebugIterator. A nice way to learn how iterators work is to set this
> iterator, use "debug on" at the shell and start scanning different ways.
>
> There are two possible solutions that I see. One is to make all iterators
> delivered with Accumulo implement OptionDescriber, and document this shell
> quirk, or to use reflection in the shell code to see if the iterator class
> implements OptionDescriber, otherwise just ensure it implements
> SortedKeyValueIterator.
>

On Tuesday, November 8, 2011 3:05:03 PM, "Jim Klucar" <[EMAIL PROTECTED]> wrote:
> Currently the
> org.apache.accumulo.core.util.shell.commands.SetIterCommand
> requires that the iterator implement the OptionDescriber interface
> (line
> 128). This prevents using some useful iterators at the shell, for
> instance
> the DebugIterator. A nice way to learn how iterators work is to set
> this
> iterator, use "debug on" at the shell and start scanning different
> ways.

Iterators can also be configured manually in the shell using the config command.
For example, you could set the debug iterator as follows:

config -t tablename -s table.iterator.scan.debug=100,org.apache.accumulo.core.iterators.DebugIterator

You can also set options/parameters for iterators that require them with further config commands.

The issue with allowing setiter to configure iterators that do not implement OptionDescriber is that there is no way for the shell (or the user) to know if the iterators require options or not.  It would have to configure them without options, then the user would have to look at the code or documentation to determine the required options and set those manually with config.

We could consider requiring that iterators implement default parameters that would be used whenever parameters are not specified.  Then any iterator could be configured with setiter.  However, it can be confusing for users if the default parameters are not obvious -- I had one user expect that removing the maxVersions parameter for the VersioningIterator would stop it from restricting the number of versions, when in fact the default for maxVersions is 1.

Billie

Billie,

Using Java reflection, you could determine what interfaces the iterator
implements, and if it implements OptionDescriber, prompt for the options.

At the very least, a better error message should be produced, currently it
just throws a ClassCastException

On Thu, Nov 10, 2011 at 3:13 PM, Billie J Rinaldi <[EMAIL PROTECTED]
> wrote:

> On Tuesday, November 8, 2011 3:05:03 PM, "Jim Klucar" <[EMAIL PROTECTED]>
> wrote:
> > Currently the
> > org.apache.accumulo.core.util.shell.commands.SetIterCommand
> > requires that the iterator implement the OptionDescriber interface
> > (line
> > 128). This prevents using some useful iterators at the shell, for
> > instance
> > the DebugIterator. A nice way to learn how iterators work is to set
> > this
> > iterator, use "debug on" at the shell and start scanning different
> > ways.
>
> Iterators can also be configured manually in the shell using the config
> command.
> For example, you could set the debug iterator as follows:
>
> config -t tablename -s
> table.iterator.scan.debug=100,org.apache.accumulo.core.iterators.DebugIterator
>
> You can also set options/parameters for iterators that require them with
> further config commands.
>
> The issue with allowing setiter to configure iterators that do not
> implement OptionDescriber is that there is no way for the shell (or the
> user) to know if the iterators require options or not.  It would have to
> configure them without options, then the user would have to look at the
> code or documentation to determine the required options and set those
> manually with config.
>
> We could consider requiring that iterators implement default parameters
> that would be used whenever parameters are not specified.  Then any
> iterator could be configured with setiter.  However, it can be confusing
> for users if the default parameters are not obvious -- I had one user
> expect that removing the maxVersions parameter for the VersioningIterator
> would stop it from restricting the number of versions, when in fact the
> default for maxVersions is 1.
>
> Billie
>

On Tuesday, November 15, 2011 10:51:56 AM, "Jim Klucar" <[EMAIL PROTECTED]>:
> Using Java reflection, you could determine what interfaces the
> iterator
> implements, and if it implements OptionDescriber, prompt for the
> options.

I guess what I'm trying to get at is that we can't assume that an iterator that doesn't implement OptionDescriber doesn't require options.  We could end up configuring an iterator that throws exceptions in the tserver because its options aren't set, which seems like a more opaque problem to deal with (although I think things are set up so that shouldn't break the tserver).

> At the very least, a better error message should be produced,
> currently it
> just throws a ClassCastException

Perhaps we could have an error message that tells the user to configure the iterator with config instead of setiter when the iterator doesn't implement OptionDescriber.

Billie

On Tue, Nov 15, 2011 at 11:03 AM, Billie J Rinaldi <
[EMAIL PROTECTED]> wrote:

> On Tuesday, November 15, 2011 10:51:56 AM, "Jim Klucar" <
> [EMAIL PROTECTED]>:
> > Using Java reflection, you could determine what interfaces the
> > iterator
> > implements, and if it implements OptionDescriber, prompt for the
> > options.
>
> I guess what I'm trying to get at is that we can't assume that an iterator
> that doesn't implement OptionDescriber doesn't require options.  We could
> end up configuring an iterator that throws exceptions in the tserver
> because its options aren't set, which seems like a more opaque problem to
> deal with (although I think things are set up so that shouldn't break the
> tserver).
>
> > At the very least, a better error message should be produced,
> > currently it
> > just throws a ClassCastException
>
> Perhaps we could have an error message that tells the user to configure
> the iterator with config instead of setiter when the iterator doesn't
> implement OptionDescriber.
>
> Billie
>
+1 for the latter. Admittedly, iterator stuff is best left for more
advanced users, but we shouldn't discourage people from trying things out
in the shell.