Rob, when DiskDV becomes the default DVFormat, would it not make sense to load the values into the cache if someone uses FieldCache API? Vs. if someone calls DV API directly, he uses whatever is the default Codec, or the one that he plugs.
That's what I would expect from a 'cache'. So it's ok that currently all FieldCache does is delegate the call to DV API, but perhaps we'd want to change that so that in the DiskDV case, it actually caches things? Or, you'd like to keep FieldCache API for sort of back-compat with existing features, and let the app control the "caching" by using an explicit RamDVFormat? Shai On Mon, Aug 12, 2013 at 7:07 PM, Ross Woolf <r...@rosswoolf.com> wrote: > Yes, I will open an issue. > > > On Mon, Aug 12, 2013 at 10:02 AM, Robert Muir <rcm...@gmail.com> wrote: > > > On Mon, Aug 12, 2013 at 8:48 AM, Ross Woolf <r...@rosswoolf.com> wrote: > > > Okay, just for clarity sake, what you are saying is that if I make the > > > FieldCache call it won't actually create and impose the loading time of > > the > > > FieldCache, but rather just use the NumericDocValuesField instead. Is > > this > > > correct? > > > > Yes, exactly. its a little confusing, but a tradeoff to make docvalues > > work transparently with lots of existing code built off of fieldcache > > (sorting/grouping/joins/faceting/...) without having to have 2 > > separate implementations of what is the same thing. so its like > > "docvalues is a fieldcache you already built at index-time". > > > > > > > > Also, my similarity was extending SimilarityBase, and I can't see how > to > > > get a docId as it is not passed in the score method "score(BasicStats > > > stats, float freq, float docLen)". Will I need to extend using > > Similarity > > > instead of SimilarityBase, or is there a way to get the docId using > > > SimilarityBase? > > > > Maybe we should just add a 'int doc' parameter to the > > SimilarityBase.score() method? Do you want to open a JIRA issue for > > this? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > >
