lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Johnson <jej2...@gmail.com>
Subject Re: Lucene/Solr 5.0 and custom FieldCahe implementation
Date Tue, 25 Aug 2015 11:03:33 GMT
Thanks Mikhail.  If I'm reading the SimpleFacets class correctly, out
delegates to DocValuesFacets when facet method is FC, what used to be
FieldCache I believe.  DocValuesFacets either uses DocValues or builds then
using the UninvertingReader.

I am not seeing a clean extension point to add a custom UninvertingReader
to Solr, would the only way be to copy the FacetComponent and SimpleFacets
and modify as needed?
On Aug 25, 2015 12:42 AM, "Mikhail Khludnev" <mkhludnev@griddynamics.com>
wrote:

> 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 <jej2003@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>
> <mkhludnev@griddynamics.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message