Private data within SOLR Schema

[Manuel Portela <ma...@gmail.com>]

Hi all,

I'm wondering how to handle following scenario:

There is a pool of data which can be searched by all users via a web
interface. Now some users would like to add own documents, or private fields
to existing documents which shall not be accessable by others.

Concerning private fields
.. I could i.e. prefix user data with an identifier, which would be
automatically be prepended as OR clause in the search. Well, it's a hack
which I don't like and I don't even know if this will work for phrases ...
... I could widen the schema to add user specific fields, I know there is no
performance impact on empty fields, but it still does not feel right to add
fields for each customer. Do I have to rebuild the index each time I add a
field?

Concerning private Documents
... I could add a scope field where a user document holds the user's
identifier(ID) or "public", when it's for public view
... I could use distributed search and add a shard per user ... could work,
but aint the planned use of distributed search I guess

Well, nothing what fits my tummy. This scenario could get even funnier, when
customers demand to have a nindividual schema, is this when I need to look
at couch or mongo?

Maybe Erick Erickson already answered my questions and I should just add
fields as I need them while dropping any db knowledge.
Could someone please guide me.

kindest regards,

Manuel

Re: Private data within SOLR Schema

[Lance Norskog <go...@gmail.com>]

A problem with this as recently surfaced: spelling suggestions. A
spelling checker built from the index pulls all terms. You cannot give
it a filter query. But, you don't want to show people words from
documents they should not see.

On Fri, Aug 27, 2010 at 12:01 PM, Lance Norskog <go...@gmail.com> wrote:
> User security tends to change often. You may find it easier to use
> user/role security. You could create a unique role for a user's docs
> and store that role instead. You need a separate user->role database.
> Later, the user can choose to share docs with someone else and you
> would then change the mapping.
>
> And yes, you really want to do this with a front-end application.
> Almost anything serious should be done with an app.
>
> Lance
>
> On Fri, Aug 27, 2010 at 10:58 AM, kenf_nc <ke...@realestate.com> wrote:
>>
>> my feeling is that private fields in a public document will be the hardest
>> nut to crack, unless you have an intermediary layer that users call instead
>> of hitting your solr instance directly. If you front it with a web service
>> you could handle various authorization scenarios a little easier.
>>
>> Private documents, the inclusion of a user_id field is an acceptable way to
>> go IMO.
>>
>> And individualized schema is actually probably the easiest thing to do. My
>> schema allows almost any type of document to be stored at the users
>> discretion, no schema changes on my part. Something like that, or slightly
>> modified version of that, would handle user defined schemas.
>> --
>> View this message in context: http://lucene.472066.n3.nabble.com/Private-data-within-SOLR-Schema-tp1376174p1376355.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
>
>
>
> --
> Lance Norskog
> goksron@gmail.com
>



-- 
Lance Norskog
goksron@gmail.com

Re: Private data within SOLR Schema

[Lance Norskog <go...@gmail.com>]

User security tends to change often. You may find it easier to use
user/role security. You could create a unique role for a user's docs
and store that role instead. You need a separate user->role database.
Later, the user can choose to share docs with someone else and you
would then change the mapping.

And yes, you really want to do this with a front-end application.
Almost anything serious should be done with an app.

Lance

On Fri, Aug 27, 2010 at 10:58 AM, kenf_nc <ke...@realestate.com> wrote:
>
> my feeling is that private fields in a public document will be the hardest
> nut to crack, unless you have an intermediary layer that users call instead
> of hitting your solr instance directly. If you front it with a web service
> you could handle various authorization scenarios a little easier.
>
> Private documents, the inclusion of a user_id field is an acceptable way to
> go IMO.
>
> And individualized schema is actually probably the easiest thing to do. My
> schema allows almost any type of document to be stored at the users
> discretion, no schema changes on my part. Something like that, or slightly
> modified version of that, would handle user defined schemas.
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Private-data-within-SOLR-Schema-tp1376174p1376355.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>



-- 
Lance Norskog
goksron@gmail.com

Re: Private data within SOLR Schema

[kenf_nc <ke...@realestate.com>]

my feeling is that private fields in a public document will be the hardest
nut to crack, unless you have an intermediary layer that users call instead
of hitting your solr instance directly. If you front it with a web service
you could handle various authorization scenarios a little easier.

Private documents, the inclusion of a user_id field is an acceptable way to
go IMO.

And individualized schema is actually probably the easiest thing to do. My
schema allows almost any type of document to be stored at the users
discretion, no schema changes on my part. Something like that, or slightly
modified version of that, would handle user defined schemas.
-- 
View this message in context: http://lucene.472066.n3.nabble.com/Private-data-within-SOLR-Schema-tp1376174p1376355.html
Sent from the Solr - User mailing list archive at Nabble.com.