I am curious about your intent when you write "!workspace1", this is equivalent to every possible authorization except workspace1. I am wondering if you actually wanted something more restrictive though, like the set of all possible workspaces except workspace1? Do you want to write something like "b & workspace[2-inf]"? Where workspace[2-inf] is made up syntax that means all workspaces with followed by an integer GTE 2.
On Thu, Mar 20, 2014 at 10:36 AM, sfeng88 <[email protected]>wrote: > I currently work on the same project as Jeff. To elaborate on the Jeff's > posts, here are some more detailed scenarios of why the NOT operator would > be helpful. > > scenario 1 - hide a value from users "using" workspace1 > > > temporarily add "& !workspace1" to data you want to exclude > > row1 cf1-col1:value1 [] > cf1-col2:value2 [a] > row2 cf1-col1:value3 [b] > cf1-col2:value4 [b & !workspace1] > > 1) user A scans the table providing authorizations [a,b] > --> sees all 4 values > > 2) user B scans the table providing authorization [a] > --> sees value1, value2 > > 3) user A when using workspace1 scans the table providing > authorizations [a,b,workspace1] > --> is prevented from seeing value4 > > > scenario 2 - hide workspace data from other users > > > add "& workspace2" to private data > > row1 cf1-col1:value1 [] > cf1-col2:value2 [a] > row2 cf1-col1:value3 [b] > cf1-col2:value4 [b & !workspace1] > row3 cf1-col1:value5 [workspace2] > cf1-col2:value6 [a & b & workspace2] > > 4) user A scans the table providing authorizations [a,b] > --> sees the 4 original values > > 5) user B scans the table providing authorization [a] > --> sees value1, value2 > > 6) user A when using workspace2 scans the table providing > authorizations [a,b,workspace2] > --> sees all 6 values > > > scenario 3 - publish workspace data > > > remove "& workspace2" from data no longer required to be private > > row1 cf1-col1:value1 [] > cf1-col2:value2 [a] > row2 cf1-col1:value3 [b] > cf1-col2:value4 [b & !workspace1] > row3 cf1-col1:value5 [workspace2] --> change to [] > cf1-col2:value6 [a & b & workspace2] --> change to [a & b] > > 7) user A scans the table providing authorizations [a,b] > --> sees the 4 original values and newly published value5, value6 > > 8) user B scans the table providing authorization [a] > --> sees value1, value2 and newly published value5 > > > scenario 4 - failsecure data > > > no additional data is return when no authorizations are provided > > row1 cf1-col1:value1 [] > cf1-col2:value2 [a] > row2 cf1-col1:value3 [b] > cf1-col2:value4 [b & !workspace1] > row3 cf1-col1:value5 [workspace2] > cf1-col2:value6 [a & b & workspace2] > > 9) user A scans the table with no authorizations > --> sees only the unmarked value1 (3 fewer than allowed in scenario 2) > > 10) user B scans the table with no authorizations > -- sees only the unmarked value1 (1 fewer than allowed in scenario 2) > > > > > -- > View this message in context: > http://apache-accumulo.1065345.n5.nabble.com/NOT-operator-in-visibility-string-tp7949p8314.html > Sent from the Users mailing list archive at Nabble.com. >
