lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-1789) getDocValues should provide a MultiReader DocValues abstraction
Date Fri, 07 Aug 2009 10:28:14 GMT


Michael McCandless commented on LUCENE-1789:

Or... how about if we made a separate "helper" class, whose purpose
was to accept a top-level reader and do "down low" switching to this
new MultiDocValues class.  This class would be deprecated, ie, exist
only in 2.9 to help external usage of the DocValues API migrate to "up
high" switching.

However, you'd have to explicitly create this class.  EG, in the
normal DocValues classes we throw an exception if you pass in a
top-level reader, noting clearly that you could 1) switch to this
helper class (at a sizable per-lookup performance hit), or 2) switch
to looking up your values per-segment?

This way at least it'd be much clearer to the external consumer the
cost of using the "down low" switching class.  It'd make the decision
explicit, not silent, on upgrading to 2.9.

> getDocValues should provide a MultiReader DocValues abstraction
> ---------------------------------------------------------------
>                 Key: LUCENE-1789
>                 URL:
>             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:
For additional commands, e-mail:

View raw message