I need to apologize I believe that in my example I have too grossly over simplified the problem and it's not clear what I am trying to do, so I'll try again.
I have a situation where I have a set of access controls say user, super user and ultra user. These controls are not necessarily hierarchical in that user < super user < ultra user. Each of these controls should only be able to see documents from with some combination of access controls they have. In my actual case we have many access controls and they can be combined in a number of fashions so I can't simply constrain what they are searching by a query alone (i.e. if it's a user the query is auth:user AND (some query)). Now I have a case where a document contains information that a user can see but also contains information a super user can see. Our current system marks this document at the super user level and the user can't see it. We now have a requirement to make the pieces that are at the user level available to the user while still allowing the super user to see and search all the information. My original thought was to simply index the document twice, this would end up in a possible duplicate (say if a user had both user and super user) but since this situation is rare it may not matter. After coming across the grouping capability in solr I figured I could execute a group query where we grouped on some key which indicated that 2 documents were the same just with different access controls (user and super user in this example). We could then filter out the documents in the group the user isn't allowed to see and only keep the document with the access controls they have. I hope this makes more sense, unfortunately the Join queries I don't believe will work because I don't think if I create documents which would be relevant to each access control I could search across these document as if it was a single document (i.e. search for something in the user document and something in the super user document in a single query). This lead me to believe that grouping was the way to go in this case, but again I am very interested in any suggestions that the community could offer. On Wed, Mar 21, 2012 at 8:41 PM, Jamie Johnson <jej2...@gmail.com> wrote: > Join looks interesting for this as well, is this currently supported > in SolrCloud? > > On Wed, Mar 21, 2012 at 6:56 PM, Jamie Johnson <jej2...@gmail.com> wrote: >> What would you recommend instead, I had thought about block join perhaps I'm >> open to suggestions tbough >> >> >> On Wednesday, March 21, 2012, Martijn v Groningen >> <martijn.v.gronin...@gmail.com> wrote: >>> I'm not sure if grouping is the right feature to use for your >>> requirements... Grouping does have an impact on performance which you need >>> to take into account. >>> Depending on what grouping features you're going to use (grouped facets, >>> ngroups), grouping performs well on large indices if you use filters >>> queries well. >>> (E.g. 100M travel offers, but during searching only interrested in in >>> travel offers to specific destinations or in a specific period of time). >>> Best way to find this out, is to just try it out. >>> >>> On 21 March 2012 22:34, Jamie Johnson <jej2...@gmail.com> wrote: >>> >>>> I was wondering how much more intensive grouping queries are in >>>> general. I am considering using grouping queries as my primary query >>>> because I have the need to store a document as pieces with varying >>>> access controls, for instance a portion of a document a user can see >>>> but an admin can see the entire thing (I'm greatly simplifying this). >>>> My thought was to do a grouping request and group on a field which >>>> contained a key which the documents all shared, but I am worried about >>>> how well this will perform at scale. Any thoughts/suggestions on this >>>> would be appreciated. >>>> >>> >>> >>> >>> -- >>> Met vriendelijke groet, >>> >>> Martijn van Groningen >>>
