I know this seems facetious, but.... Talk to your clients about _why_ they want such increasingly complex access requirements. Often the logic is pretty flawed for the complexity. Things like "allow user X to see document Y if they're part of groups A, B, C but not D or E unless they are also part of sub-group F and it's raining outside"...
If the rules _must_ be complicated, that's what post-filters were actually invented for. Pretty often I'll build in some "bailout" because whatever you build has, eventually, to deal with the system admin searching all documents, i.e. doing the ACL calcs for every document. Best, Erick On Mon, May 23, 2016 at 6:02 PM, Lisheng Zhang <lz0522...@gmail.com> wrote: > Hi, i have been using solr for many years and it is VERY helpful. > > My problem is that our app has an increasingly more complicated access > control to satisfy client's requirement, in solr/lucene it means we need > to add more and more fields into each document and use more and more > complicated filter conditions, so code is hard to maintain and indexing > becomes a serious issue because we want to search as real time as possible. > > I would appreciate a high level guidance on how to deal with this issue? > recently i investigated mySQL fulltext search (our app uses mySQL), using > mySQL means we simply reuse DB for access control, but mySQL fulltext > search performance is far from ideal compared to solr. > > Thanks very much for helps, Lisheng
