Below are the reasons why I thought it wouldn't be feasible to have
pre-filtered results with filter queries. please comment.
Since can't pen down direct business reqs due to confidentially contact with
the client, I'll mock out scenario using an example.
- There is a parent entity called "Quiz", which has multiple "assignees".
Quiz has one-to-many with another entity called "Schools" and "School" has
multiple "Assessors".
-There are two separate indexes
1) for Quiz, Quiz title, details, status are the searchable attributes of
the Quiz and stored in the Quiz index.
2) School index. which has school name, and some other school related
searchable attributes in the index
now for e.g. when someone searches against Quiz title, search results will
be returned to the application. before displaying results following access
rules kick in from the application. they are nothing but java rules from the
application, which decide whether person can view a particular quiz document
(returned from Solr).
-Rule first checks against an external entitlement service which has
authorization policy defining entitlement roles. This external entitlement
service first returns "true" or "false" that whether person can "view"
"quiz" entity or not.
-If it returned false then that document is thrown out from the
resultset.
-If it returned "true" then further check in the rule is; check
assignees of the quiz(from the database), if person who logged in is
one of the assignees of that quiz document, which s/he is trying to view. If
yes then only s/he can view else not.
-There is a super admin role in the entitlement service (again this is
external to our app). If logged in person is super admin then s/he can view
document. No need to check quiz assignments.
If I store quiz assignees into the index then on the fly update of a
document in the index would be too slow (yes we do update/insert index
documents on the fly when a new record is created or updated in the db).
Plus as I mentioned for super admin role there aren't any assignments. If I
decide to store super admins into the index, then it would mean there will
have to be some asynchronous thread running against entitlement service and
monitor this "super admin" role, everytime new person is added to that role,
add him to each indexed document's assignment list?
The whole above thing looked too convoluted. Hence thought it would be clean
to leverage existing application logic (rules) and continue post processing.
That way pagination can work correctly if solr retruned resultset is also
filtered. If solr returned resultset isn't filtered then pagination won't
work correctly as application wouldn't know how many documents will be
kicked out (can't know how many "next" links to paint)
Sorry for the lengthy post but thought describing entire scenario would make
things clear from requirement and infrastructure point of view.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Custom-request-handler-plugin-tp2673822p2674913.html
Sent from the Solr - User mailing list archive at Nabble.com.
