Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Row level visibility


Copy link to this message
-
Re: Row level visibility
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
>>>> >
>>>>
>>>
>>>
>