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
