It kind of sounds like you could manage this much easier by controlling
the authorizations a user gets (notably the workspace name) and the
grant/revoke above the Accumulo level.
A sandbox has a unique label and the external system controls which
users are granted that label. This way, each sandbox can be modified
individually (using authorizations that contain the data visibility and
the sandbox label) or the original data set could be modified (by
omitting a sandbox label in the authorizations used).
Is that accurate?
On 3/19/14, 12:05 PM, Jeff Kunkle wrote:
I attempted to simplify the scenario to facilitate discussion, which on
second thought may have been a mistake. Here’s the whole scenario:
Different users have access to different subsets of the data depending
on their authorizations and the visibility of the data. Users “work
with” the data in what we call a sandbox. Sanboxes can be shared with
other users (this is the group creation I was talking about earlier).
Deletes to the data would be “scoped” to the sandbox by changing the
visibility to add “& !workspace_name” so that people viewing the
workspace wouldn’t see the data but everyone else would.
On Mar 19, 2014, at 11:48 AM, Sean Busbey <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Mar 19, 2014 at 10:43 AM, Jeff Kunkle <[email protected]
<mailto:[email protected]>> wrote:
New groups are created on the fly by our application when needed.
Under the scenario you describe we’d have to go through all the
data in Accumulo whenever a group is created so that users in the
group can see the existing data.
Ah! So your use case is that all data defaults to world readable and
then users have the option of opting out of seeing subsets. Right?
In your scenario user groups also get to opt-out of seeing data on the
fly, yes? Both require rewriting the data. Does the group creation
happen more often?
