Hi All, I think using filter queries will be a good option to consider because of the following reasons
* The filter query does not affect the score of the items in the result set. If the ACL logic is part of the main query, it could influence the scores of the items in the result set. * Using a filter query could lead to better performance in complex queries because the results from the query specified with fq are cached independently from that of the main query. Since the result of a filter query is cached, it will be used to filter the primary query result using set intersection without having to fetch the ids of the documents from the fq again a second time. It think this will be useful because we could assume that the ACL portion in the fq is relatively constant since the permissions for each user is not something that is changing frequently. http://wiki.apache.org/solr/FilterQueryGuidance On Sat, Oct 23, 2010 at 2:58 PM, Dennis Gearon <gear...@sbcglobal.net>wrote: > why use filter queries? > > Wouldn't reducing the set headed into the filters by putting it in the main > query be faster? (A question to learn, since I do NOT know :-) > > Dennis Gearon > > Signature Warning > ---------------- > It is always a good idea to learn from your own mistakes. It is usually a > better idea to learn from others’ mistakes, so you do not have to make them > yourself. from ' > http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' > > EARTH has a Right To Life, > otherwise we all die. > > > --- On Sat, 10/23/10, Israel Ekpo <israele...@gmail.com> wrote: > > > From: Israel Ekpo <israele...@gmail.com> > > Subject: Re: Modelling Access Control > > To: solr-user@lucene.apache.org > > Date: Saturday, October 23, 2010, 7:01 AM > > Hi Paul, > > > > Regardless of how you implement it, I would recommend you > > use filter queries > > for the permissions check rather than making it part of the > > main query. > > > > On Sat, Oct 23, 2010 at 4:03 AM, Paul Carey <paul.p.ca...@gmail.com> > > wrote: > > > > > Hi > > > > > > My domain model is made of users that have access to > > projects which > > > are composed of items. I'm hoping to use Solr and > > would like to make > > > sure that searches only return results for items that > > users have > > > access to. > > > > > > I've looked over some of the older posts on this > > mailing list about > > > access control and saw a suggestion along the lines > > of > > > acl:<user_id> AND (actual query). > > > > > > While this obviously works, there are a couple of > > niggles. Every item > > > must have a list of valid user ids (typically less > > than 100 in my > > > case). Every time a collaborator is added to or > > removed from a > > > project, I need to update every item in that project. > > This will > > > typically be fewer than 1000 items, so I guess is no > > big deal. > > > > > > I wondered if the following might be a reasonable > > alternative, > > > assuming the number of projects to which a user has > > access is lower > > > than a certain bound. > > > (acl:<project_id> OR acl:<project_id> OR > > ... ) AND (actual query) > > > > > > When the numbers are small - e.g. each user has access > > to ~20 projects > > > and each project has ~20 collaborators - is one > > approach preferable > > > over another? And when outliers exist - e.g. a project > > with 2000 > > > collaborators, or a user with access to 2000 projects > > - is one > > > approach more liable to fail than the other? > > > > > > Many thanks > > > > > > Paul > > > > > > > > > > > -- > > °O° > > "Good Enough" is not good enough. > > To give anything less than your best is to sacrifice the > > gift. > > Quality First. Measure Twice. Cut Once. > > http://www.israelekpo.com/ > > > -- °O° "Good Enough" is not good enough. To give anything less than your best is to sacrifice the gift. Quality First. Measure Twice. Cut Once. http://www.israelekpo.com/
