Constraints are a pluggable system as well, so there still may be options through those to provide the level of interaction that you require.
On Sun, Jan 26, 2014 at 11:26 PM, Nehal Mehta <[email protected]> wrote: > We have ported graph database Titan <http://titan.thinkaurelius.com/> to > use accumulo as storage engine. In graph, suppose we have N number of > nodes. We want one set of users to create edges connecting those nodes. We > want other users to add more edges using already created edges/nodes to > same group. but not able to update those edges as they may not have > permission to those. > > Our graph would end up having billions of edges, so can't have them their > own tables as retrieving from those tables would be even complex. So yes > "One set of owner, larger set of consumer" set up is required to have that. > > Thanks, > Nehal > > > > > On Sun, Jan 26, 2014 at 11:05 PM, John Vines <[email protected]> wrote: > >> 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 >>>> > >>>> >>> >>> >
