[
https://issues.apache.org/jira/browse/LUCENE-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15235324#comment-15235324
]
Alan Woodward commented on LUCENE-5325:
---------------------------------------
Some stuff I've been working on has touched this, and I think I have a possible
way forward. One of the issues I have with ValueSource is that it's inherently
type-unsafe - you have no way of saying what sort of value you want from a
ValueSource input. However, pretty much all the VS consumers we have only
actually use a single type: expressions uses doubleVal(), facet uses longVal()
for LongRange and doubleVal() for DoubleRange, function queries use floatVal(),
etc.
I propose we add a new set of abstract classes to the core search package,
exposing per-document Long, Double and BytesRef values. We add some simple
wrapper methods to the queries module to convert a ValueSource to a
LongValuesSource/DoubleValuesSource/BytesRefValuesSource. Then we can go
through each module and convert it to use the core classes instead of
ValueSource, one by one. This breaks things up into the subtasks Ryan was
talking about, and allows us to defer worrying about some of the wartier
aspects of the current ValueSource API (quite a few of which are only used by a
single module, and can be narrowed down to a module-specific subclass or
implementation).
I have the start of a patch for this, which I can upload if people think this
sounds like a good idea, cutting over expressions and facets.
> Move ValueSource and FunctionValues under core/
> -----------------------------------------------
>
> Key: LUCENE-5325
> URL: https://issues.apache.org/jira/browse/LUCENE-5325
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Reporter: Shai Erera
>
> Spinoff from LUCENE-5298: ValueSource and FunctionValues are abstract APIs
> which exist under the queries/ module. That causes any module which wants to
> depend on these APIs (but not necessarily on any of their actual
> implementations!), to depend on the queries/ module. If we move these APIs
> under core/, we can eliminate these dependencies and add some mock impls for
> testing purposes.
> Quoting Robert from LUCENE-5298:
> {quote}
> we should eliminate the suggest/ dependencies on expressions and queries, the
> expressions/ on queries, the grouping/ dependency on queries, the spatial/
> dependency on queries, its a mess.
> {quote}
> To add to that list, facet/ should not depend on queries too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
