lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From caman <ABoxForTheOtherSt...@gmail.com>
Subject Re: Document model suggestion
Date Mon, 21 Dec 2009 23:19:10 GMT

Lance,
Makes sense. We are playing around with keeping the security model
completely out of Index. We will filter out results before data display
based on access rights. But approach you suggested is not ruled out
completely.
thanks

Lance Norskog-2 wrote:
> 
> Yes, you would have 'role' as a multi-valued field. When you add
> someone to a role, you don't have to re-index. That's all.
> 
> On Thu, Dec 17, 2009 at 12:55 PM, caman <ABoxForTheOtherStuff@gmail.com>
> wrote:
>>
>> Are you suggesting that roles should be maintained in the index? We do
>> manage
>> out authentication based on roles but at granular level, user rights play
>> a
>> big role as well.
>> I know we need to compromise, just need to find a balance.
>>
>> Thanks
>>
>>
>> Lance Norskog-2 wrote:
>>>
>>> Role-based authentication is one level of sophistication up from
>>> user-based authentication. Users can have different roles, and
>>> authentication goes against roles. Documents with multiple viewers
>>> would be assigned special roles. All users would also have their own
>>> matching role.
>>>
>>> On Tue, Dec 15, 2009 at 10:01 AM, caman <ABoxForTheOtherStuff@gmail.com>
>>> wrote:
>>>>
>>>> Erick,
>>>> I know what you mean.
>>>> Wonder if it is actually cleaner to keep the authorization  model out
>>>> of
>>>> solr index and filter the data at client side based on the user access
>>>> rights.
>>>> Thanks all for help.
>>>>
>>>>
>>>>
>>>> Erick Erickson wrote:
>>>>>
>>>>> Yes, that should work. One hard part is what happens if your
>>>>> authorization model has groups, especially when membership
>>>>> in those groups changes. Then you have to go in and update
>>>>> all the affected docs.....
>>>>>
>>>>> FWIW
>>>>> Erick
>>>>>
>>>>> On Tue, Dec 15, 2009 at 12:24 PM, caman
>>>>> <ABoxForTheOtherStuff@gmail.com>wrote:
>>>>>
>>>>>>
>>>>>> Shalin,
>>>>>>
>>>>>> Thanks. much appreciated.
>>>>>> Question about:
>>>>>>  "That is usually what people do. The hard part is when some
>>>>>> documents
>>>>>> are
>>>>>> shared across multiple users. "
>>>>>>
>>>>>> What do you recommend when documents has to be shared across multiple
>>>>>> users?
>>>>>> Can't I just multivalue a field with all the users who has access
to
>>>>>> the
>>>>>> document?
>>>>>>
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> Shalin Shekhar Mangar wrote:
>>>>>> >
>>>>>> > On Tue, Dec 15, 2009 at 7:26 AM, caman
>>>>>> > <ABoxForTheOtherStuff@gmail.com>wrote:
>>>>>> >
>>>>>> >>
>>>>>> >> Appreciate any guidance here please. Have a master-child
table
>>>>>> between
>>>>>> >> two
>>>>>> >> tables 'TA' and 'TB' where form is the master table. Any
row in TA
>>>>>> can
>>>>>> >> have
>>>>>> >> multiple row in TB.
>>>>>> >> e.g. row in TA
>>>>>> >>
>>>>>> >> id---name
>>>>>> >> 1---tweets
>>>>>> >>
>>>>>> >> TB:
>>>>>> >> id|ta_id|field0|field1|field2.....|field20|created_by
>>>>>> >> 1|1|value1|value2|value2.....|value20|User1
>>>>>> >>
>>>>>> >> <snip/>
>>>>>> >
>>>>>> >>
>>>>>> >> This works fine and index the data.But all the data for
a row in
>>>>>> TA
>>>>>> gets
>>>>>> >> combined in one document(not desirable).
>>>>>> >> I am not clear on how to
>>>>>> >>
>>>>>> >> 1) separate a particular row from the search results.
>>>>>> >> e.g. If I search for 'Android' and there are 5 rows for
android in
>>>>>> TB
>>>>>> for
>>>>>> >> a
>>>>>> >> particular instance in TA, would like to show them separately
to
>>>>>> user
>>>>>> and
>>>>>> >> if
>>>>>> >> the user click on any of the row,point them to an attached
URL in
>>>>>> the
>>>>>> >> application. Should a separate index be maintained for each
row in
>>>>>> TB?TB
>>>>>> >> can
>>>>>> >> have millions of rows.
>>>>>> >>
>>>>>> >
>>>>>> > The easy answer is that whatever you want to show as results
should
>>>>>> be
>>>>>> the
>>>>>> > thing that you index as documents. So if you want to show tweets
as
>>>>>> > results,
>>>>>> > one document should represent one tweet.
>>>>>> >
>>>>>> > Solr is different from relational databases and you should not
>>>>>> think
>>>>>> about
>>>>>> > both the same way. De-normalization is the way to go in Solr.
>>>>>> >
>>>>>> >
>>>>>> >> 2) How to protect one user's data from another user. I guess
I can
>>>>>> keep
>>>>>> a
>>>>>> >> column for a user_id in the schema and append that filter
>>>>>> automatically
>>>>>> >> when
>>>>>> >> I search through SOLR. Any better alternatives?
>>>>>> >>
>>>>>> >>
>>>>>> > That is usually what people do. The hard part is when some
>>>>>> documents
>>>>>> are
>>>>>> > shared across multiple users.
>>>>>> >
>>>>>> >
>>>>>> >> Bear with me if these are newbie questions please, this
is my
>>>>>> first
>>>>>> day
>>>>>> >> with
>>>>>> >> SOLR.
>>>>>> >>
>>>>>> >>
>>>>>> > No problem. Welcome to Solr!
>>>>>> >
>>>>>> > --
>>>>>> > Regards,
>>>>>> > Shalin Shekhar Mangar.
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://old.nabble.com/Document-model-suggestion-tp26784346p26798445.html
>>>>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/Document-model-suggestion-tp26784346p26799016.html
>>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Lance Norskog
>>> goksron@gmail.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Document-model-suggestion-tp26784346p26834798.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Lance Norskog
> goksron@gmail.com
> 
> 

-- 
View this message in context: http://old.nabble.com/Document-model-suggestion-tp26784346p26881664.html
Sent from the Solr - User mailing list archive at Nabble.com.


Mime
View raw message