Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
>>>> >
>>>>
>>>
>>>
>

 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB