Another option (assuming the case where a user can be granted access to a certain class of documents, and more than one user would be able to access certain documents) would be to store the access filter (as an OR query of content types) in an external cache (perhaps a database or an eternal cache that the database changes are published to periodically), then using this access filter as a facet on the base query.
-sujit On Wed, 2011-02-09 at 14:38 -0500, Glen Newton wrote: > > This application will be built to serve many users > > If this means that you have thousands of users, 1000s of VMs and/or > 1000s of cores is not going to scale. > > Have an ID in the index for each user, and filter using it. > Then they can see only their own documents. > > Assuming that you are building an app that through which they > authenticate & talks to solr . > (i.e. all requests are filtered using their ID) > > -Glen > > On Wed, Feb 9, 2011 at 2:31 PM, Greg Georges <greg.geor...@biztree.com> wrote: > > From what I understand about multicore, each of the indexes are independant > > from each other right? Or would one index have access to the info of the > > other? My requirement is like you mention, a client has access only to his > > or her search data based in their documents. Other clients have no access > > to the index of other clients. > > > > Greg > > > > -----Original Message----- > > From: Darren Govoni [mailto:dar...@ontrenet.com] > > Sent: 9 février 2011 14:28 > > To: solr-user@lucene.apache.org > > Subject: Re: Architecture decisions with Solr > > > > What about standing up a VM (search appliance that you would make) for > > each client? > > If there's no data sharing across clients, then using the same solr > > server/index doesn't seem necessary. > > > > Solr will easily meet your needs though, its the best there is. > > > > On Wed, 2011-02-09 at 14:23 -0500, Greg Georges wrote: > > > >> Hello all, > >> > >> I am looking into an enterprise search solution for our architecture and I > >> am very pleased to see all the features Solr provides. In our case, we > >> will have a need for a highly scalable application for multiple clients. > >> This application will be built to serve many users who each will have a > >> client account. Each client will have a multitude of documents to index > >> (0-1000s of documents). After discussion we were talking about going > >> multicore and to have one index file per client account. The reason for > >> this is that security is achieved by having a separate index for each > >> client etc.. Is this the best approach? How feasible is it (dynamically > >> create indexes on client account creation. Is it better to go the faceted > >> search capabilities route? Thanks for your help > >> > >> Greg > > > > > > > > >
