[jira] Commented: (SOLR-936) Facet Results - REST vs SolrJ

2008-12-23 Thread Andrew Nagy (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658934#action_12658934
 ] 

Andrew Nagy commented on SOLR-936:
--

Yes - thanks - this does solve my problem.

In regards to the "Applied Facets" it might be nice to separate the list of 
returned facets to a list of available facets and a list of "applied" facets.

What is driving this idea is my curiosity on how to build a list of facets that 
uses checkboxes instead of links.  How do I know if the checkboxes should be 
checked or not with out saving some state information about what the user 
clicked on.  It would be nice if solr could do this for me by either flagging 
the facets that are in my fq or by keeping them in a different list.

> Facet Results - REST vs SolrJ
> -
>
> Key: SOLR-936
> URL: https://issues.apache.org/jira/browse/SOLR-936
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java, search
>Affects Versions: 1.4
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> There is a difference in the way Facet results are reported in SolrJ from the 
> REST interface.  In REST, if you apply a facet via the fq param, no matter 
> what the count it is always reported back in the list of facets in the 
> responses.  However, with SolrJ - it only reports back facets that don't 
> match the total number of documents.  This is quite frustrating to deal with. 
>  
> The difference can be seen when ORing or ANDing in the fq param.  When I or 
> to facet values together, they come back in SolrJ since their counts don't 
> match the total docs.  But if I AND them together, they don't appear in the 
> list.  So then I need to munge in the applied fq values.
> Why the difference in behavior between REST and SolrJ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SOLR-936) Facet Results - REST vs SolrJ

2008-12-23 Thread Andrew Nagy (JIRA)

 [ 
https://issues.apache.org/jira/browse/SOLR-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Nagy resolved SOLR-936.
--

Resolution: Invalid

> Facet Results - REST vs SolrJ
> -
>
> Key: SOLR-936
> URL: https://issues.apache.org/jira/browse/SOLR-936
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java, search
>Affects Versions: 1.4
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> There is a difference in the way Facet results are reported in SolrJ from the 
> REST interface.  In REST, if you apply a facet via the fq param, no matter 
> what the count it is always reported back in the list of facets in the 
> responses.  However, with SolrJ - it only reports back facets that don't 
> match the total number of documents.  This is quite frustrating to deal with. 
>  
> The difference can be seen when ORing or ANDing in the fq param.  When I or 
> to facet values together, they come back in SolrJ since their counts don't 
> match the total docs.  But if I AND them together, they don't appear in the 
> list.  So then I need to munge in the applied fq values.
> Why the difference in behavior between REST and SolrJ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-936) Facet Results - REST vs SolrJ

2008-12-23 Thread Andrew Nagy (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658871#action_12658871
 ] 

Andrew Nagy commented on SOLR-936:
--

It might also be beneficial to have a list of "Applied Facets" so we can 
differentiate whether a facet has been applied and what the count is for that 
facet.

> Facet Results - REST vs SolrJ
> -
>
> Key: SOLR-936
> URL: https://issues.apache.org/jira/browse/SOLR-936
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java, search
>Affects Versions: 1.4
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> There is a difference in the way Facet results are reported in SolrJ from the 
> REST interface.  In REST, if you apply a facet via the fq param, no matter 
> what the count it is always reported back in the list of facets in the 
> responses.  However, with SolrJ - it only reports back facets that don't 
> match the total number of documents.  This is quite frustrating to deal with. 
>  
> The difference can be seen when ORing or ANDing in the fq param.  When I or 
> to facet values together, they come back in SolrJ since their counts don't 
> match the total docs.  But if I AND them together, they don't appear in the 
> list.  So then I need to munge in the applied fq values.
> Why the difference in behavior between REST and SolrJ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Reopened: (SOLR-936) Facet Results - REST vs SolrJ

2008-12-23 Thread Andrew Nagy (JIRA)

 [ 
https://issues.apache.org/jira/browse/SOLR-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Nagy reopened SOLR-936:
--


I am referring to the code in SolrJ that filters out any facets with the same 
count as the total number of search results.  This is different from the REST 
interface.

See the bottom of:
http://svn.apache.org/viewvc/lucene/solr/trunk/src/solrj/org/apache/solr/client/solrj/response/FacetField.java?revision=724175&view=markup

Solrj filters out facet values where as the raw output from the REST interface 
does not.

> Facet Results - REST vs SolrJ
> -
>
> Key: SOLR-936
> URL: https://issues.apache.org/jira/browse/SOLR-936
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java, search
>Affects Versions: 1.4
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> There is a difference in the way Facet results are reported in SolrJ from the 
> REST interface.  In REST, if you apply a facet via the fq param, no matter 
> what the count it is always reported back in the list of facets in the 
> responses.  However, with SolrJ - it only reports back facets that don't 
> match the total number of documents.  This is quite frustrating to deal with. 
>  
> The difference can be seen when ORing or ANDing in the fq param.  When I or 
> to facet values together, they come back in SolrJ since their counts don't 
> match the total docs.  But if I AND them together, they don't appear in the 
> list.  So then I need to munge in the applied fq values.
> Why the difference in behavior between REST and SolrJ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SOLR-936) Facet Results - REST vs SolrJ

2008-12-22 Thread Andrew Nagy (JIRA)
Facet Results - REST vs SolrJ
-

 Key: SOLR-936
 URL: https://issues.apache.org/jira/browse/SOLR-936
 Project: Solr
  Issue Type: Bug
  Components: clients - java, search
Affects Versions: 1.4
Reporter: Andrew Nagy
Priority: Minor
 Fix For: 1.4


There is a difference in the way Facet results are reported in SolrJ from the 
REST interface.  In REST, if you apply a facet via the fq param, no matter what 
the count it is always reported back in the list of facets in the responses.  
However, with SolrJ - it only reports back facets that don't match the total 
number of documents.  This is quite frustrating to deal with.  

The difference can be seen when ORing or ANDing in the fq param.  When I or to 
facet values together, they come back in SolrJ since their counts don't match 
the total docs.  But if I AND them together, they don't appear in the list.  So 
then I need to munge in the applied fq values.

Why the difference in behavior between REST and SolrJ?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit

2008-08-28 Thread Andrew Nagy (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626621#action_12626621
 ] 

Andrew Nagy commented on SOLR-737:
--

Sorry to keep blathering on - but I am trying to understand this issue better.

If I issue the query (r* AND fisher) the results come back to me immediately 
... no slow down what so ever.  And an r* is going to have many many more 
possibilities than r*a* - it still seems like there is a bug here.

Can anyone clarify how lucene handles this?

> Incorrect 500 error reported with maxClausCount limit
> -
>
> Key: SOLR-737
> URL: https://issues.apache.org/jira/browse/SOLR-737
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> Here is my installation:
> Solr Specification Version: 1.2.2008.08.13.13.05.16
> Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25
> I did the following query today:
> author:(r*a* AND fisher)
> And get the following 500 error:
> maxClauseCount is set to 1024
> org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set 
> to 1024
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165)
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156)
> at 
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63)
> at 
> org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54)
> at 
> org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385)
> at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163)
> at org.apache.lucene.search.Query.weight(Query.java:94)
> at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175)
> at org.apache.lucene.search.Searcher.search(Searcher.java:126)
> at org.apache.lucene.search.Searcher.search(Searcher.java:105)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
> at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
> at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit

2008-08-28 Thread Andrew Nagy (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626619#action_12626619
 ] 

Andrew Nagy commented on SOLR-737:
--

Thanks Mark for clarification.  This makes sense now.  Solr does already have a 
configurable maxClauseCount and the default is 1024.

Can anyone supply more information on whether or not this is something that can 
be enhanced in Lucene - for me this is a very important query and since I have 
well over a million documents - I will never be able to issue this query.

> Incorrect 500 error reported with maxClausCount limit
> -
>
> Key: SOLR-737
> URL: https://issues.apache.org/jira/browse/SOLR-737
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> Here is my installation:
> Solr Specification Version: 1.2.2008.08.13.13.05.16
> Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25
> I did the following query today:
> author:(r*a* AND fisher)
> And get the following 500 error:
> maxClauseCount is set to 1024
> org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set 
> to 1024
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165)
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156)
> at 
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63)
> at 
> org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54)
> at 
> org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385)
> at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163)
> at org.apache.lucene.search.Query.weight(Query.java:94)
> at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175)
> at org.apache.lucene.search.Searcher.search(Searcher.java:126)
> at org.apache.lucene.search.Searcher.search(Searcher.java:105)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
> at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
> at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-737) Incorrect 500 error reported with maxClausCount limit

2008-08-28 Thread Andrew Nagy (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626611#action_12626611
 ] 

Andrew Nagy commented on SOLR-737:
--

Why has this been relegated to an improvement and held to 1.4?

This is a major showstopper bug for me - unless I am understanding something 
incorrectly?


> Incorrect 500 error reported with maxClausCount limit
> -
>
> Key: SOLR-737
> URL: https://issues.apache.org/jira/browse/SOLR-737
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> Here is my installation:
> Solr Specification Version: 1.2.2008.08.13.13.05.16
> Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25
> I did the following query today:
> author:(r*a* AND fisher)
> And get the following 500 error:
> maxClauseCount is set to 1024
> org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set 
> to 1024
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165)
> at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156)
> at 
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63)
> at 
> org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54)
> at 
> org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385)
> at 
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163)
> at org.apache.lucene.search.Query.weight(Query.java:94)
> at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175)
> at org.apache.lucene.search.Searcher.search(Searcher.java:126)
> at org.apache.lucene.search.Searcher.search(Searcher.java:105)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
> at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088)
> at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
> at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
> at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at 
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SOLR-737) Incorrect 500 error reported with maxClausCount limit

2008-08-28 Thread Andrew Nagy (JIRA)
Incorrect 500 error reported with maxClausCount limit
-

 Key: SOLR-737
 URL: https://issues.apache.org/jira/browse/SOLR-737
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Andrew Nagy
 Fix For: 1.3


Here is my installation:
Solr Specification Version: 1.2.2008.08.13.13.05.16
Lucene Implementation Version: 2.4-dev 685576 - 2008-08-13 10:55:25

I did the following query today:
author:(r*a* AND fisher)

And get the following 500 error:

maxClauseCount is set to 1024

org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set to 
1024
at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165)
at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156)
at 
org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:63)
at org.apache.lucene.search.WildcardQuery.rewrite(WildcardQuery.java:54)
at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:385)
at 
org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:163)
at org.apache.lucene.search.Query.weight(Query.java:94)
at org.apache.lucene.search.Searcher.createWeight(Searcher.java:175)
at org.apache.lucene.search.Searcher.search(Searcher.java:126)
at org.apache.lucene.search.Searcher.search(Searcher.java:105)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:966)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:838)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:269)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:160)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:167)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1156)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:829)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at 
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (SOLR-710) Solr cannot find jar's in Multicore sharedLib directory

2008-08-19 Thread Andrew Nagy (JIRA)

 [ 
https://issues.apache.org/jira/browse/SOLR-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Nagy closed SOLR-710.


Resolution: Invalid

Sorry for the false alarm - I don't know what I was doing wrong before but its 
working now.

> Solr cannot find jar's in Multicore sharedLib directory
> ---
>
> Key: SOLR-710
> URL: https://issues.apache.org/jira/browse/SOLR-710
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.3
>
>
> I am using the UnicodeNormalizationFilterFactory developed by Robert Haschart 
> and have added the jar to my solr/lib directory.  This worked great until i 
> implemented the multicore with the solr.xml file.  However now with the 
> multicore feature in place, solr can no longer find the jar containing the 
> unicode filter.
> I set the sharedLib attribute to ./solr/lib, just lib and to 
> /usr/local/solr/lib - all three times I had the same result - it could not 
> find the jar.
> When I copy the lib directory into my core directory (still with the 
> sharedLib dir set to ./solr/lib) everything works.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SOLR-710) Solr cannot find jar's in Multicore sharedLib directory

2008-08-19 Thread Andrew Nagy (JIRA)
Solr cannot find jar's in Multicore sharedLib directory
---

 Key: SOLR-710
 URL: https://issues.apache.org/jira/browse/SOLR-710
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Andrew Nagy
 Fix For: 1.3


I am using the UnicodeNormalizationFilterFactory developed by Robert Haschart 
and have added the jar to my solr/lib directory.  This worked great until i 
implemented the multicore with the solr.xml file.  However now with the 
multicore feature in place, solr can no longer find the jar containing the 
unicode filter.

I set the sharedLib attribute to ./solr/lib, just lib and to 
/usr/local/solr/lib - all three times I had the same result - it could not find 
the jar.

When I copy the lib directory into my core directory (still with the sharedLib 
dir set to ./solr/lib) everything works.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SOLR-523) Solr Schema - version number requirements

2008-08-13 Thread Andrew Nagy (JIRA)

 [ 
https://issues.apache.org/jira/browse/SOLR-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Nagy updated SOLR-523:
-

Fix Version/s: 1.4

Assigning this to 1.4 as to not effect the release of 1.3

> Solr Schema - version number requirements
> -
>
> Key: SOLR-523
> URL: https://issues.apache.org/jira/browse/SOLR-523
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Andrew Nagy
>Priority: Minor
> Fix For: 1.4
>
>
> When I change the version number of the solr schema from 1.0 or 1.1 to 
> something arbitrary like say 0.8.1 - solr reports a parsing error with the 
> schema - however, a version number "0.8" is accepted.  It would be nice if 
> solr reporting an "invalid schema version" error instead or atleast put 
> something in the log that has a bit more detail.
> You could add in a check in src/java/org/apache/solr/schema/IndexSchema.java 
> that might look like this:
> Node node = (Node) xpath.evaluate("/schema/@version", document, 
> XPathConstants.NODE);
> if (!("1.0".equals(node) || "1.1".equals(node))) {
> log.warning("invalid schema version - use 1.0 or 1.1 only");
> }
> It's quite poor to hardcode the version numbers - but I thought I should 
> include something to give you a more concrete idea of what I am talking about.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SOLR-691) Standardized XML Response

2008-08-12 Thread Andrew Nagy (JIRA)
Standardized XML Response
-

 Key: SOLR-691
 URL: https://issues.apache.org/jira/browse/SOLR-691
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Andrew Nagy
Priority: Minor


It would be nice for parsing Solr output if all output followed a standardized 
XML schema.

For example: add, commit, optimize, etc. all return the following:

But do not include an XML declaration line.

When Solr throws an error - we get a standard java backtrace.  It would be nice 
if this was formated in XML as well with something to the effect of:





-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SOLR-523) Solr Schema - version number requirements

2008-03-31 Thread Andrew Nagy (JIRA)
Solr Schema - version number requirements
-

 Key: SOLR-523
 URL: https://issues.apache.org/jira/browse/SOLR-523
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.2
Reporter: Andrew Nagy
Priority: Minor


When I change the version number of the solr schema from 1.0 or 1.1 to 
something arbitrary like say 0.8.1 - solr reports a parsing error with the 
schema - however, a version number "0.8" is accepted.  It would be nice if solr 
reporting an "invalid schema version" error instead or atleast put something in 
the log that has a bit more detail.

You could add in a check in src/java/org/apache/solr/schema/IndexSchema.java 
that might look like this:

Node node = (Node) xpath.evaluate("/schema/@version", document, 
XPathConstants.NODE);
if (!("1.0".equals(node) || "1.1".equals(node))) {
log.warning("invalid schema version - use 1.0 or 1.1 only");
}

It's quite poor to hardcode the version numbers - but I thought I should 
include something to give you a more concrete idea of what I am talking about.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support

2007-05-25 Thread Andrew Nagy (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499198
 ] 

Andrew Nagy commented on SOLR-69:
-

A really nice feature would be to allow for boosting for fields, for example:

?q=id:1&mlt=true&mlt.fl=title^5,author^3,topic

This would find items that are more similar to the title over the author, etc.

> PATCH:MoreLikeThis support
> --
>
> Key: SOLR-69
> URL: https://issues.apache.org/jira/browse/SOLR-69
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Attachments: lucene-queries-2.0.0.jar, lucene-queries-2.1.1-dev.jar, 
> SOLR-69-MoreLikeThisRequestHandler.patch, 
> SOLR-69-MoreLikeThisRequestHandler.patch, 
> SOLR-69-MoreLikeThisRequestHandler.patch, SOLR-69.patch, SOLR-69.patch, 
> SOLR-69.patch, SOLR-69.patch
>
>
> Here's a patch that implements simple support of Lucene's MoreLikeThis class.
> The MoreLikeThisHelper code is heavily based on (hmm..."lifted from" might be 
> more appropriate ;-) Erik Hatcher's example mentioned in 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00878.html
> To use it, add at least the following parameters to a standard or dismax 
> query:
>   mlt=true
>   mlt.fl=list,of,fields,which,define,similarity
> See the MoreLikeThisHelper source code for more parameters.
> Here are two URLs that work with the example config, after loading all 
> documents found in exampledocs in the index (just to show that it seems to 
> work - of course you need a larger corpus to make it interesting):
> http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=standard&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score
> http://localhost:8983/solr/select/?stylesheet=&q=apache&qt=dismax&mlt=true&mlt.fl=manu,cat&mlt.mindf=1&mlt.mindf=1&fl=id,score
> Results are added to the output like this:
> 
>   ...
>   
> 
>   
> 1.5293242
> SOLR1000
>   
> 
> 
>   
> 1.5293242
> UTF8TEST
>   
> 
>   
> I haven't tested this extensively yet, will do in the next few days. But 
> comments are welcome of course.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.