Thanks Robert for all your thoughts and context! > I feel that things like facets apis should really try to move to lower-level > apis (DoubleValuesSource, SortedSetDocValues, etc)
Yeah I think this direction generally makes sense. All the cases I can think of where a user might want to provide custom values (e.g., filtering, transforming, etc.) could be solved by allowing users to pass their own xxDocValues instance into faceting implementations. For example, if a user wanted to provide some filtering or transformation on long values before counting them with LongValueFacetCounts, they could do so by creating their own SortedNumericDocValues / NumericDocValues implementations and passing them in if the faceting implementations supported this. The only possible gap I see here is that implementing xxDocValues requires the ability to provide iteration over the documents themselves, whereas xxValuesSource doesn't. So if there was some case where a user wanted to provide multi-valued data but couldn't provide document iteration, that might be an issue. It's a bit of a funny limitation since faceting doesn't need the value source to lead iteration, so I could see a multi-valued version of something like LongValuesSource maybe being a better fit. Cheers, -Greg On Tue, Oct 26, 2021 at 8:03 PM Robert Muir <[email protected]> wrote: > > On Tue, Oct 26, 2021 at 8:01 PM Robert Muir <[email protected]> wrote: > > > > Hi Greg, I think the general issue is one of the API, the ValueSource > > seems really geared at returning values from single-valued fields. > > I think really, this is the core issue. This ValueSource thing was > created before the days of docvalues, in a lot of cases will do > inefficient things depending on how you hold it. > > I feel that things like facets apis should really try to move to > lower-level apis (DoubleValuesSource, SortedSetDocValues, etc) > > Reverse the problem around from push to a pull, now if you want to > give "computed field" or similar inputs to faceting (e.g. some kind of > filtering-on-the-fly), you have the chance to implement it > efficiently. > The expressions module switched away from this ValueSource to a > DoubleValues/DoubleValuesSource already, though I didn't follow > specific reasons why. > Maybe similar approaches apply to all the numerics. > > As far as the strings, personally, I'm not sure what a ValueSource API > that "filters/transforms" terms should look like. Seems slow no matter > how you do it. But maybe fresh ideas are needed. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
