Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of yseeley@gmail.com designates
 209.85.219.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:reply-to:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=lCTZpMznDJt45/IHA4UcYgUrl31IHN6VbwpXsYAyWASZIEtuL1tXzgb25sjDTkefQY
         2QXXXlR7n0KKnn3XrmTXwHAs/PrOovx7H5nCptNb5MaSt2dgj48jKZhvZ10f85y/7wuu
         vSLng/x3T67nZxUX/wEZKmTNUQOUIOkRkXOc8=
MIME-Version: 1.0
Sender: yseeley@gmail.com
Reply-To: yonik@lucidimagination.com
In-Reply-To: <4ACB60BB.7020400@gmail.com>
References: <4ACB60BB.7020400@gmail.com>
Date: Tue, 6 Oct 2009 11:50:50 -0400
Message-ID: <c68e39170910060850q427791e1l99ae206835293c1e@mail.gmail.com>
Subject: Re: De-basing / re-basing docIDs, or how to effectively pass
	calculated values from a Scorer or Filter up to (Solr's)
 QueryComponent.process
From: Yonik Seeley <yonik@lucidimagination.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Aaron, could you move this to solr-user?

-Yonik
http://www.lucidimagination.com


On Tue, Oct 6, 2009 at 11:22 AM, Aaron McKee <ucbmckee@gmail.com> wrote:
>
> In the code I'm working with, I generate a cache of calculated values as a
> by-product within a Filter.getDocidSet implementation (and within a
> Query-ized version of the filter and its Scorer method) . These values are
> keyed off the IndexReader's docID values, since that's all that's accessible
> at that level. Ultimately, however, I need to be able to access these values
> much higher up in the stack (Solr's QueryComponent.process method), so that
> I can inject the dynamic values into the response as a fake field. The IDs
> available here, however, are for the entire index and not just relative to
> the current IndexReader. I'm still fairly new to Lucene and I've been
> scratching my head a bit trying to find a reliable way to map these values
> into the same space, without having to hack up too many base classes. I
> noticed that there was a related discussion at:
>
> http://issues.apache.org/jira/browse/LUCENE-1821?focusedCommentId=12745041#action_12745041
>
> ... but also a bit of disagreement on the suggested strategies. Ideally, I'm
> also hoping there's a strategy that won't require me to hack up too much of
> the core product; subclassing IndexSearcher in the way suggested would
> basically require me to change all of the various SearchComponents I use in
> Solr, and that sounds like it'd end up a real maintenance nightmare. I was
> looking at the Collector class as possible solution, since it has knowledge
> of the docbase, but it looks like I'd then need to change every derived
> collector that the code ultimately uses and, including the various anonymous
> Collectors in Solr, that also looks like it'd be a fairly ghoulish solution.
> I suppose I'm being wishful, or lazy, but is there a reasonable and reliable
> way to do this, without having to fork the core code? If not, any suggestion
> on the best strategy to accomplish this, without adding too much overhead
> every time I wanted to up-rev the core Lucene and/or Solr code to the latest
> version?
>
> Thanks a ton,
> Aaron

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org