On 22 March 2012 03:10, Jamie Johnson <jej2...@gmail.com> wrote:
> 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.
>
Maybe I'm not understanding this right... But why can't you save the access
controls
as a multivalued field in your schema? In your example your can then if the
current user is a normal user just query auth:user AND (query) and if the
current user
is a super user auth:superuser AND (query). A document that is searchable
for
both superuser and user is then returned (if it matches the rest of the
query).
>
> 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.
>
I wouldn't use grouping. The Solr join is still a option. Lets say you have
many access controls and the access controls change often on your documents.
You can then choose to store the access controls with an id to your logic
document
as a separate document in a different Solr Core (index). In the core were
your main
documents are you don't keep the access controls. You can then use the solr
join
to filter out documents that the current user isn't supposed to search.
Something like this:
q=(query)&fq={!join fromIndex=core1 from=doc_id to=id}auth:superuser
Core 1 is the core containing the access control documents and the doc_id
is the id that
points to your regular documents.
The benefit of this approach is that if you fine tune the core1 for high
updatability you can
change you access controls very frequently without paying a big
performance penalty.
