Re: svn commit: r763791 - /lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/QueryResponse.java
I think this is the same as SOLR-1021? If yes, we can mark that issue as
resolved.
On Fri, Apr 10, 2009 at 1:54 AM, r...@apache.org wrote:
Author: ryan
Date: Thu Apr 9 20:24:34 2009
New Revision: 763791
URL: http://svn.apache.org/viewvc?rev=763791view=rev
Log:
fix potential NPE with FieldStatsInfo
Modified:
lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/QueryResponse.java
Modified:
lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/QueryResponse.java
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/QueryResponse.java?rev=763791r1=763790r2=763791view=diff
==
---
lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/QueryResponse.java
(original)
+++
lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/QueryResponse.java
Thu Apr 9 20:24:34 2009
@@ -131,8 +131,11 @@
NamedListNamedListObject ff = (NamedListNamedListObject)
info.get( stats_fields );
if( ff != null ) {
for( Map.EntryString,NamedListObject entry : ff ) {
- _fieldStatsInfo.put( entry.getKey(),
- new FieldStatsInfo( entry.getValue(), entry.getKey() ) );
+ NamedListObject v = entry.getValue();
+ if( v != null ) {
+_fieldStatsInfo.put( entry.getKey(),
+new FieldStatsInfo( v, entry.getKey() ) );
+ }
}
}
}
--
Regards,
Shalin Shekhar Mangar.
Re: LUCENE-1516 and near real time search
On Fri, Apr 10, 2009 at 12:42 AM, Grant Ingersoll gsing...@apache.orgwrote: https://issues.apache.org/jira/browse/LUCENE-1516 Has anyone looked yet at how https://issues.apache.org/jira/browse/LUCENE-1516 might be used in Solr? Seems like it might allow us to speed up searcher turnaround. WDYT? I have been following those discussions closely but I do not understand all the details. Let us get 1.4 out of the door and start on this asap. -- Regards, Shalin Shekhar Mangar.
Re: Contributing Translations
On Fri, Apr 10, 2009 at 8:10 AM, Green Crescent Translations ad...@greentranslations.com wrote: Hello, I'm a project manager for Green Crescent Translations and I'm always looking to assist the open source community by providing translations of web sites, manuals, user interfaces and such. If you're interested, please let us know. We'd be happy to translate you web site documentation into needed languages. Just let me know which languages and what texts are essential and we'd be happy to help. Wow, this is great! Thank you for the offer Jonathan! This can be a huge boost to Solr. What do people think? How about we run a poll through our user mailing list to see what are the most common languages in the Solr community? I don't know if we already track our website visitor's languages (Google Analytics does this but we don't use it). -- Regards, Shalin Shekhar Mangar.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697872#action_12697872 ] Grant Ingersoll commented on SOLR-773: -- Anyone know the status on this one? Incorporate Local Lucene/Solr - Key: SOLR-773 URL: https://issues.apache.org/jira/browse/SOLR-773 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Priority: Minor Attachments: SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, spatial-solr.tar.gz Local Lucene has been donated to the Lucene project. It has some Solr components, but we should evaluate how best to incorporate it into Solr. See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Contributing Translations
Hello Shalin, Sure, we're actually using Solr for a project we're working on and thought it would be nice to lend a hand. Great software. Do you have any current translations or would this be something totally new? I'd guess the place to start would be Spanish or maybe Russian. Chinese, Japanese and French are also big. I'd guess Solr can generate a whole new audience if translated into the right languages. Do you have an essential text that we could take a look at to start with? Or maybe we could start with the website? Just let me know... be happy to help. Thanks, Jonathan At 06:36 AM 4/10/2009, you wrote: On Fri, Apr 10, 2009 at 8:10 AM, Green Crescent Translations ad...@greentranslations.com wrote: Hello, I'm a project manager for Green Crescent Translations and I'm always looking to assist the open source community by providing translations of web sites, manuals, user interfaces and such. If you're interested, please let us know. We'd be happy to translate you web site documentation into needed languages. Just let me know which languages and what texts are essential and we'd be happy to help. Wow, this is great! Thank you for the offer Jonathan! This can be a huge boost to Solr. What do people think? How about we run a poll through our user mailing list to see what are the most common languages in the Solr community? I don't know if we already track our website visitor's languages (Google Analytics does this but we don't use it). -- Regards, Shalin Shekhar Mangar. Jonathan W. Fabian Project Manager (888) 963 0006 - U.S. Toll Free (702) 966 5160 - International (702) 966 5130 - Fax www.greencrescent.com
[jira] Updated: (SOLR-1092) DIH can have a new command import which does not clean
[ https://issues.apache.org/jira/browse/SOLR-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1092: - Attachment: SOLR-1092.patch DIH can have a new command import which does not clean Key: SOLR-1092 URL: https://issues.apache.org/jira/browse/SOLR-1092 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1092.patch full-import is slightly risky that it cleans the index if we fail to mention clean= false. We must add a command import which will work like full-import and does not clean -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1092) DIH can have a new command import which does not clean
[ https://issues.apache.org/jira/browse/SOLR-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697896#action_12697896 ] Noble Paul commented on SOLR-1092: -- this also fixes the bug where clean is done even if clean=false is set DIH can have a new command import which does not clean Key: SOLR-1092 URL: https://issues.apache.org/jira/browse/SOLR-1092 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1092.patch full-import is slightly risky that it cleans the index if we fail to mention clean= false. We must add a command import which will work like full-import and does not clean -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-825) The ConstantScore family of queries does not work with highlighting
[ https://issues.apache.org/jira/browse/SOLR-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697945#action_12697945 ] Mark Miller commented on SOLR-825: -- With LUCENE-1424 and 1425 committed, I think this is now possible with Solr. It will only work with the Phrase Highlighter, but thats probably the highlighter you should be using anyway (highlighting phrases properly is nice and expected, and its not any slower for non phrase highlighting). Still need a patch and a Lucene jar upgrade though. I will be happy to see highlightable wildcard/range queries again. The ConstantScore family of queries does not work with highlighting --- Key: SOLR-825 URL: https://issues.apache.org/jira/browse/SOLR-825 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.3 Reporter: Mark Miller Priority: Minor Fix For: 1.4 Would be nice to be able to highlight range, wildcard, prefix queries again. LUCENE-1424, LUCENE-1425, updating Lucene jars, and a patch from this issue, will get us there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
creating ingestion document from multiple data extractions
I have multiple data source for single product sku that combine to make the total metadata for a product. Currently, I these systems extract to xml flatflies that 3 files that have hundreds of records each but have joinable keys. spec metadata sku=abc keyword metadata sku=abc related product metadata sku=abc The only thing I could like of was to use one as primary to add and other 2 to update then publish the whole new index -- View this message in context: http://www.nabble.com/creating-ingestion-document-from-multiple-data-extractions-tp22994298p22994298.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Assigned: (SOLR-825) The ConstantScore family of queries does not work with highlighting
[ https://issues.apache.org/jira/browse/SOLR-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi reassigned SOLR-825: --- Assignee: Koji Sekiguchi The ConstantScore family of queries does not work with highlighting --- Key: SOLR-825 URL: https://issues.apache.org/jira/browse/SOLR-825 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 1.3 Reporter: Mark Miller Assignee: Koji Sekiguchi Priority: Minor Fix For: 1.4 Would be nice to be able to highlight range, wildcard, prefix queries again. LUCENE-1424, LUCENE-1425, updating Lucene jars, and a patch from this issue, will get us there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694851#action_12694851 ] Dave Redford edited comment on SOLR-236 at 4/10/09 6:47 PM: There is an issue with collapsed result ordering when querying with only the unique Id and score fields in the request. [Update: this is only an issue when both standard results and collapse results are present - which I was using for testing] eg: q=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 gives wrong ordering (note: Id is our unique Id) but adding a another field - even a bogus one - works. q=fordversion=2.2start=0rows=10indent=onfl=Id,score,boguscollapse.field=PrimaryIdcollapse.max=1 Also using an fq makes it work eg: fq=Type:articlesq=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 I'm using the latest Dmitry patch (25/mar/09) against 1.3.0. Apart from that great so far...thanks to all was (Author: dredford): There is an issue with collapsed result ordering when querying with only the unique Id and score fields in the request. [Update: this is only an issue when both standard results and collapse results are present - which I was using for testing] eg: q=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 gives wrong ordering (note: Id is our unique Id) but adding a another field - even a bogus one - works. q=fordversion=2.2start=0rows=10indent=onfl=Id,score,boguscollapse.field=PrimaryIdcollapse.max=1 Also using an fq makes it work eg: fq=Type:articlesq=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 I'm using the latest Dmitry patch (25/mar/09) against 1.3.0. Apart from that great so far... Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.5 Attachments: collapsing-patch-to-1.3.0-dieter.patch, collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, collapsing-patch-to-1.3.0-ivan_3.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694851#action_12694851 ] Dave Redford edited comment on SOLR-236 at 4/10/09 6:46 PM: There is an issue with collapsed result ordering when querying with only the unique Id and score fields in the request. [Update: this is only an issue when both standard results and collapse results are present - which I was using for testing] eg: q=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 gives wrong ordering (note: Id is our unique Id) but adding a another field - even a bogus one - works. q=fordversion=2.2start=0rows=10indent=onfl=Id,score,boguscollapse.field=PrimaryIdcollapse.max=1 Also using an fq makes it work eg: fq=Type:articlesq=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 I'm using the latest Dmitry patch (25/mar/09) against 1.3.0. Apart from that great so far... was (Author: dredford): There is an issue with collapsed result ordering when querying with only the unique Id and score fields in the request. eg: q=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 gives wrong ordering (note: Id is our unique Id) but adding a another field - even a bogus one - works. q=fordversion=2.2start=0rows=10indent=onfl=Id,score,boguscollapse.field=PrimaryIdcollapse.max=1 Also using an fq makes it work eg: fq=Type:articlesq=fordversion=2.2start=0rows=10indent=onfl=Id,scorecollapse.field=PrimaryIdcollapse.max=1 I'm using the latest Dmitry patch (25/mar/09) against 1.3.0. Apart from that great so far... Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.5 Attachments: collapsing-patch-to-1.3.0-dieter.patch, collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, collapsing-patch-to-1.3.0-ivan_3.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
