SearchComponent is the class I was missing. Looks like if I can provide an
entirely new implementation of that it will be a lot cleaner than the hack I
had been using in 1.2 over top of facets. What I'm doing is implementing
some aggregation functions like avg() and sum() that SQL has. This way I
can send back the top 100 results to the UI, but I can also say things like
"the average price over all 900 product results from your query is X". I'd
always wanted to take this functionality and give it back to the Solr
community, but it always felt like too much of a hack to submit it before.
Now maybe I can come up with a clean implementation that I'm not ashamed of
submitting :)
Thanks for the help.
Mark Baird
On Fri, Sep 19, 2008 at 2:39 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
>
> On Sep 19, 2008, at 11:49 AM, Mark Baird wrote:
>
> I was finally given the go-ahead to upgrade from Solr 1.2 to 1.3 in our
>> environment here at work now that 1.3 is final. However I'm running into
>> a
>> couple problems that I'm having trouble finding solutions to.
>>
>> First, I've added a class to our Solr distribution that extends
>> StandardRequestHandler. In particular it overrides getFacetInfo and uses
>> this to compute some aggregate values. Here's my code:
>>
>> protected NamedList getFacetInfo(SolrQueryRequest req, SolrQueryResponse
>> rsp, DocSet mainSet)
>> {
>> // Call the super class to get it's response first
>> NamedList res = super.getFacetInfo(req, rsp, mainSet);
>>
>> // Now calculate all sums
>> NamedList aggregates = new NamedList();
>> try
>> {
>> aggregates.addAll(this.computeSums(req, mainSet));
>> aggregates.addAll(this.computeAverages(req, mainSet));
>> }
>> catch (IOException e)
>> {
>> e.printStackTrace();
>> SolrException.logOnce(SolrCore.log, "Exception during aggregate
>> value calculations", e);
>> return res;
>> }
>>
>> // add the aggregate fields to the response
>> res.add("facet_aggregates", aggregates);
>> return res;
>> }
>>
>> However now StandardRequestHandler doesn't seem to implement the
>> getFacetInfo() method anymore. Did this method move to another class
>> somewhere? Or do I need to just do this aggregate stuff in a totally
>> different way in 1.3?
>>
>
>
> Not sure about aggregating, but the faceting is now handled in
> FacetComponent, thus, you probably need to override that with your own
> version.
>
>
>>
>>
>> Second, I've got some code running in the same JVM as Solr that does some
>> stuff like getting the latest timestamp in the index to determine if we
>> need
>> to pull an update from our product info database, kicking off an optimize
>> every night at 2:00AM, stuff like that. However I take it that this line
>> won't work anymore due to the multicore stuff:
>> SolrCore core = SolrCore.getSolrCore();
>> That's fine, but how do I get a handle to the SolrCore intance(s) now?
>> The
>> SolrCore.getSolrCore method was static, the method in CoreContainer that
>> replaces it is not static, so how, by just being in the same JVM, can a
>> class get access to the CoreContainer?
>>
>
> It's available in the SolrDispatchFilter, so it might be reasonable to
> extend that.
>
>
>>
>>
>>
>> The only other thing I'm seeing is some deprecation messages using the
>> FieldType.getValueSource(SchemaField field) method. The source looks like
>> this:
>>
>> /** called to get the default value source (normally, from the
>> * Lucene FieldCache.)
>> */
>> public ValueSource getValueSource(SchemaField field, QParser parser) {
>> return getValueSource(field);
>> }
>>
>>
>> /**
>> * @deprecated use [EMAIL PROTECTED] #getValueSource(SchemaField, QParser)}
>> */
>> @Deprecated
>> public ValueSource getValueSource(SchemaField field) {
>> return new OrdFieldSource(field.name);
>> }
>>
>> Which I find a little funny. Don't use this deprecated method, use this
>> other method instead, which immediately throws away the extra parameter
>> and
>> just calls the deprecated method anyway?
>>
>
> Hmmm, that does smell. It's been that way for a while, too. I'll see if I
> can dig up why that came about.
>
