It sounds like you want a single owner, multiple consumer setup. I'm curious why you need to have it set up in a per row basis. Why not let each data producer have their own table?
Sent from my phone, please pardon the typos and brevity. On Jan 26, 2014 10:56 PM, "Nehal Mehta" <[email protected]> wrote: > Thanks John. I do understand we can define those permissions at table > level or user level. Our application needs it to be defined at row/cell > level. > > But here what we are trying to achieve is to have them at row level. So > suppose a user of group inserts data, it can be updated by same group but > not another group. Multiple other groups can still read that data. So > basically we would have to define it at row level. In that way, lot of > applications can be developed on top of accumulo without worrying about > read-update validations at application. > > Basically we want row level information to be created and updated by one > set of group but can be read by multiple groups. Multiple groups write data > to that same table. Do you think accumulo wants to support that in future? > Instead of having just cell visibility we have two set of visibility for > each cell: 1) Read Visibility 2) Write (Update) Visibility. > > Thanks, > Nehal > > > > > On Sun, Jan 26, 2014 at 9:59 PM, John Vines <[email protected]> wrote: > >> I think there may be two things which would satisfy your request. >> >> 1. For tables, there are both READ and WRITE ACLs used to determine read >> and write access. If a user does not have read permission, they will be >> unable to get any data (with READ permissions, it will then fall back to >> the authorizations). Similarly, if a user lacks the WRITE permission, they >> can't do any inserts. >> >> 2. For a user with WRITE permission, there is a constraint which can be >> applied to a table which only allows them to write data with a label they >> have permission to read. This would effectively allow cell level write >> control, in addition to read control. >> >> Hopefully that provides some insight. >> >> >> On Sun, Jan 26, 2014 at 7:51 PM, Nehal Mehta <[email protected]> wrote: >> >> > Hi, >> > >> > Is accumulo considering row level visibility for read and write >> (updates). >> > Basically in one of our application we want user to insert rows with >> > different visibility options for updating that row vs reading that row. >> We >> > want one role to be restricted to just read that row but another special >> > role to update as well as read that row. >> > >> > By having read and update visibility accumulo can expose more rows as >> there >> > is no fear of them being updated. >> > >> > I am relatively new user of accumulo and if this is already discussed in >> > past, can anyone guide me to that discussion? >> > >> > Thanks, >> > Nehal >> > >> > >
