Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 11 Sep 2012 23:20:08 +1100 (NCT)
From: "Billie Rinaldi (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <1124611915.63012.1347366008081.JavaMail.jiratomcat@arcas>
In-Reply-To: <949907188.54516.1347136327621.JavaMail.jiratomcat@arcas>
Subject: [jira] [Comment Edited] (ACCUMULO-759) remove priority setting for
 scan-time iterators
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Billie Rinaldi edited comment on ACCUMULO-759 at 9/11/12 11:19 PM:
-------------------------------------------------------------------

> However, the boolean is more restrictive than this, because it prevents insertion of an iterator at other points in the scan.

No, the boolean method could be used along with two Scanner methods:

{code:java}
something(IteratorSetting) // user handles priority, boolean set to false
something(ScanIteratorSetting) // priority is handled automatically, boolean set to true
{code}

which is not to say that I'm convinced this is the way to do it.  I kind of like the port-like method you suggest, but it does break some things people were doing before (mainly setting an iterator at priority Integer.MAX_VALUE), so I wanted to suggest a method that would not.
                
      was (Author: billie.rinaldi):
    > However, the boolean is more restrictive than this, because it prevents insertion of an iterator at other points in the scan.

No, the boolean method could be used along with two Scanner methods:

{code:java}
  something(IteratorSetting) // user handles priority, boolean set to false
  something(ScanIteratorSetting) // priority is handled automatically, boolean set to true
{code}

which is not to say that I'm convinced this is the way to do it.  I kind of like the port-like method you suggest, but it does break some things people were doing before (mainly setting an iterator at priority Integer.MAX_VALUE), so I wanted to suggest a method that would not.
                  
> remove priority setting for scan-time iterators
> -----------------------------------------------
>
>                 Key: ACCUMULO-759
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-759
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Adam Fuchs
>              Labels: newbie
>
> Iterators have a priority setting that allows a user to order iterators arbitrarily. However that priority is an integer that doesn't directly convey the iterator's relationship to other iterators. I would postulate that nobody has ever needed to sneak in a scan-time iterator underneath a configured table iterator (please let me know if I'm wrong about this), and the effect of doing so is not easy to calculate. Many people have chosen a bad iterator priority and seen commutativity problems with previously configured iterators.
> I propose that we use more of an agglomerative approach to configuring scan-time iterators, in which the order of the iterator tree is the same order in which the addScanIterator method is called, and all scan-time iterators apply after the configured iterators apply. The change to the API should just be to remove the priority number, and the existing IteratorSetting constructor and accessors should be deprecated.
> With this change, we can think of an iterator as more of a functional modification to a data set, as in T' = f(T) or T'' = g(f(T)). This should make it easier for developers to use iterators correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira