As an alternative, I think we could probably add more information to the iterator environment, like access to the authorizations service, to enable more robust filtering that these use cases require. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Mar 20, 2014 at 11:56 AM, Sean Busbey wrote: > On Thu, Mar 20, 2014 at 10:32 AM, sfeng88 > wrote: >> >> For scenario 1-3, it is a very small dataset that we will be >> adding/hiding. >> In addition, we would rather not duplicate Accumulo's Authorization code >> into our project to filter what should or should not be hidden from the >> user >> given our scenarios. >> >> Going through this entire thread, am I wrong to assume that Accumulo will >> not be accepting this patch? If so, please let us know so we can come up >> with alternative ways to solve our use cases. >> >> >> > > Hey Susan! > > We haven't called a formal vote, but from my estimation consensus within the > project is opposed to adding a NOT operator. After our pending releases are > handled, I'm going to try to pull the reasoning into a more organized > document since I expect this will come up again. > > Since I'd like that document to include some examples that can be > implemented as is, even though NOT seems like an obvious choice, I'd be > happy to help worth through how your use case can be handled without a NOT > operator. > > Did you happen to already read my earlier approach[1]? I believe it can be > used to accomplish all of the scenarios you presented. > > -Sean > > [1]: http://s.apache.org/35e