Re: Private data within SOLR Schema
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 goks...@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 ken.fos...@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 goks...@gmail.com -- Lance Norskog goks...@gmail.com
Re: Private data within SOLR Schema
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.
Re: Private data within SOLR Schema
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 ken.fos...@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 goks...@gmail.com
