Hello Jamie, I don't understand how it could choose DocValuesFacets (it occurs on docValues=true) field, but then switches to UninvertingReader/FieldCache which means docValues=false. If you can provide more details it would be great. Beside of that, I suppose you can only implement and inject your own UninvertingReader, I don't think there is an extension point for this. It's too specific requirement.
On Tue, Aug 25, 2015 at 3:50 AM, Jamie Johnson <jej2...@gmail.com> wrote: > as mentioned in a previous email I have a need to provide security controls > at the term level. I know that Lucene/Solr doesn't support this so I had > baked something onto a 4.x baseline that was sufficient for my use cases. > I am now looking to move that implementation to 5.x and am running into an > issue around faceting. Previously we were able to provide a custom cache > implementation that would create separate cache entries given a particular > set of security controls, but in Solr 5 some faceting is delegated to > DocValuesFacets which delegates to UninvertingReader in my case (we are not > storing DocValues). The issue I am running into is that before 5.x I had > the ability to influence the FieldCache that was used at the Solr level to > also include a security token into the key so each cache entry was scoped > to a particular level. With the current implementation the FieldCache > seems to be an internal detail that I can't influence in anyway. Is this > correct? I had noticed this Jira ticket > https://issues.apache.org/jira/browse/LUCENE-5427, is there any movement > on > this? Is there another way to influence the information that is put into > these caches? As always thanks in advance for any suggestions. > > -Jamie > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
