Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 69378 invoked from network); 25 Feb 2010 21:10:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Feb 2010 21:10:49 -0000 Received: (qmail 56297 invoked by uid 500); 25 Feb 2010 21:10:48 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 56271 invoked by uid 500); 25 Feb 2010 21:10:48 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 56263 invoked by uid 99); 25 Feb 2010 21:10:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 21:10:48 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 21:10:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D4216234C1F0 for ; Thu, 25 Feb 2010 13:10:27 -0800 (PST) Message-ID: <483876352.536171267132227867.JavaMail.jira@brutus.apache.org> Date: Thu, 25 Feb 2010 21:10:27 +0000 (UTC) From: "Dallan Quass (JIRA)" To: solr-dev@lucene.apache.org Subject: [jira] Updated: (SOLR-1795) Subclassing QueryComponent for fetching results from a database In-Reply-To: <1276976427.536021267132108070.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SOLR-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dallan Quass updated SOLR-1795: ------------------------------- Description: This is a request to change the access on a few fields from package to public. I've subclassed QueryComponent to allow me to fetch results from a database (based upon the stored uniqueKey field) instead of from the shards. The only stored field in solr is the uniqueKey field, and whatever fields I might need for sorting. To do this I've overridden QueryComponent.finishStage so that after executing the query, SolrDocuments are created with the uniqueKey field. A later component populates the rest of the fields in the documents by reading them from a database. {code} public void finishStage(ResponseBuilder rb) { if (rb.stage == ResponseBuilder.STAGE_EXECUTE_QUERY) { // Create SolrDocument's from the ShardDoc's boolean returnScores = (rb.getFieldFlags() & SolrIndexSearcher.GET_SCORES) != 0; for (ShardDoc sdoc : rb.resultIds.values()) { SolrDocument doc = new SolrDocument(); doc.setField("id", sdoc.id); if (returnScores && sdoc.score != null) { doc.setField("score", sdoc.score); } rb._responseDocs.set(sdoc.positionInResponse, doc); } } } {code} Everything works fine, but ResponseBuilder variables: *resultIds* and *_responseDocs*, and ShardDoc variables: *id*, *score*, and *positionInResponse* currently all have package visibility. I needed to modify the core solr files to change their visibility to public so that I could access them in the function above. Is there any chance that they could be changed to public in a future version of Solr, or somehow make them accessible outside the package? If people are interested, I could post the QueryComponent subclass and database component that I wrote. But it gets a bit involved because the QueryComponent subclass also handles parsing the query just at the main solr server, and sending serialized parsed queries to the shards. (Query parsing in my environment is pretty cpu- and memory-intensive so I do it just at the main server instead of the shards.) was: This is a request to change the access on a few fields from package to public. I've subclassed QueryComponent to allow me to fetch results from a database (based upon the stored uniqueKey field) instead of from the shards. The only stored field in solr is the uniqueKey field, and whatever fields I might need for sorting. To do this I've overridden QueryComponent.finishStage so that after executing the query, SolrDocuments are created with the uniqueKey field. A later component populates the rest of the fields in the documents by reading them from a database. {code} public void finishStage(ResponseBuilder rb) { if (rb.stage == ResponseBuilder.STAGE_EXECUTE_QUERY) { // Create SolrDocument's from the ShardDoc's boolean returnScores = (rb.getFieldFlags() & SolrIndexSearcher.GET_SCORES) != 0; for (ShardDoc sdoc : rb.resultIds.values()) { SolrDocument doc = new SolrDocument(); doc.setField(UNIQUE_KEY_FIELDNAME, sdoc.id); if (returnScores && sdoc.score != null) { doc.setField("score", sdoc.score); } rb._responseDocs.set(sdoc.positionInResponse, doc); } } } {code} Everything works fine, but ResponseBuilder variables: *resultIds* and *_responseDocs*, and ShardDoc variables: *id*, *score*, and *positionInResponse* currently all have package visibility. I needed to modify the core solr files to change their visibility to public so that I could access them in the function above. Is there any chance that they could be changed to public in a future version of Solr, or somehow make them accessible outside the package? If people are interested, I could post the QueryComponent subclass and database component that I wrote. But it gets a bit involved because the QueryComponent subclass also handles parsing the query just at the main solr server, and sending serialized parsed queries to the shards. (Query parsing in my environment is pretty cpu- and memory-intensive so I do it just at the main server instead of the shards.) > Subclassing QueryComponent for fetching results from a database > --------------------------------------------------------------- > > Key: SOLR-1795 > URL: https://issues.apache.org/jira/browse/SOLR-1795 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other > Affects Versions: 1.4 > Reporter: Dallan Quass > > This is a request to change the access on a few fields from package to public. > I've subclassed QueryComponent to allow me to fetch results from a database (based upon the stored uniqueKey field) instead of from the shards. The only stored field in solr is the uniqueKey field, and whatever fields I might need for sorting. To do this I've overridden QueryComponent.finishStage so that after executing the query, SolrDocuments are created with the uniqueKey field. A later component populates the rest of the fields in the documents by reading them from a database. > {code} > public void finishStage(ResponseBuilder rb) { > if (rb.stage == ResponseBuilder.STAGE_EXECUTE_QUERY) { > // Create SolrDocument's from the ShardDoc's > boolean returnScores = (rb.getFieldFlags() & SolrIndexSearcher.GET_SCORES) != 0; > for (ShardDoc sdoc : rb.resultIds.values()) { > SolrDocument doc = new SolrDocument(); > doc.setField("id", sdoc.id); > if (returnScores && sdoc.score != null) { > doc.setField("score", sdoc.score); > } > rb._responseDocs.set(sdoc.positionInResponse, doc); > } > } > } > {code} > Everything works fine, but ResponseBuilder variables: *resultIds* and *_responseDocs*, and ShardDoc variables: *id*, *score*, and *positionInResponse* currently all have package visibility. I needed to modify the core solr files to change their visibility to public so that I could access them in the function above. Is there any chance that they could be changed to public in a future version of Solr, or somehow make them accessible outside the package? > If people are interested, I could post the QueryComponent subclass and database component that I wrote. But it gets a bit involved because the QueryComponent subclass also handles parsing the query just at the main solr server, and sending serialized parsed queries to the shards. (Query parsing in my environment is pretty cpu- and memory-intensive so I do it just at the main server instead of the shards.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.