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

Billie Rinaldi commented on ACCUMULO-759:
-----------------------------------------

IteratorSetting is also used to configure non-scan-time iterators.  It seems 
like the change would make the table operations methods worse in favor of 
making the scanner methods only slightly better (and less functional).  This 
seems like a documentation problem, not an API problem.

What if we left the current functionality the way it is, and added a new method 
for scan iterator configuration that would ignore the priority, e.g. 
addScanIterator(IteratorSetting si, boolean ignorePriority)?
                
> 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

Reply via email to