[
https://issues.apache.org/jira/browse/LUCENE-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741464#action_12741464
]
Hoss Man commented on LUCENE-1789:
----------------------------------
bq. How about this: we add a new param to the ctors of the value sources,
called (say) acceptMultiReader. It has 3 values:
...that would work ... but i feel like there may be a cleaner API possible
here...
What if we just added a new MultiValueSource wrapper class, that acted as a
proxy around another ValueSource so that the only non-transparent behavior is
that MultiValueSource.getDocValues returns an instance of the new
MultiDocValues we've been talking about.
If you use something like FloatFieldSource directly in your code, you get what
you ask for: the FieldCache is fetched agaisnt the exact reader you supply (ie:
YES_BURN_MEMORY). If you want to use a FieldSource directly in your code, and
you want to get good cache reuse, and you don't want to sorry about the
subreaders yourself, you wrap your FieldSource in a new
MultiValueSource(myFieldSource) (YES_BURN_TIME)
The only thing this wouldn't get us is an obvious warning to developers on
upgrading (like the deprecation warnings htat would come from your suggested
API) ... but since nothing about backwards compatibility is actually breaking
here, that doesn't seem like the end of the world -- we can document it in
CHANGES.txt (we're going to need a nice big section there about all the
FieldCache usage changes anyway) drawing their attention to the new
MultiValueSource they should consider using.
My thinking is this: anybody who is constructing new ValueSOurces directly is
pretty deep into the code, odds are if they're using that type of code, they
might be mucking with the FieldCache directly in other ways as well -- we can't
solve all their problems, but we can give them helper code to make the
transition easier)
> getDocValues should provide a MultiReader DocValues abstraction
> ---------------------------------------------------------------
>
> Key: LUCENE-1789
> URL: https://issues.apache.org/jira/browse/LUCENE-1789
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Hoss Man
> Priority: Minor
> Fix For: 2.9
>
>
> When scoring a ValueSourceQuery, the scoring code calls
> ValueSource.getValues(reader) on *each* leaf level subreader -- so DocValue
> instances are backed by the individual FieldCache entries of the subreaders
> -- but if Client code were to inadvertently called getValues() on a
> MultiReader (or DirectoryReader) they would wind up using the "outer"
> FieldCache.
> Since getValues(IndexReader) returns DocValues, we have an advantage here
> that we don't have with FieldCache API (which is required to provide direct
> array access). getValues(IndexReader) could be implimented so that *IF* some
> a caller inadvertently passes in a reader with non-null subReaders, getValues
> could generate a DocValues instance for each of the subReaders, and then wrap
> them in a composite "MultiDocValues".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
