[jira] Updated: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-350: --- Attachment: solr-350.patch simplified the MultiCore singleton handling (aka SolrMultiCore.getInstance is lazily loading) but kept SolrDispatchFilter/MultiCore/MultiCoreHandler derivable. Manage Multiple SolrCores - Key: SOLR-350 URL: https://issues.apache.org/jira/browse/SOLR-350 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch In SOLR-215, we enabled support for more then one SolrCore - but there is no way to use them yet. We need to make some interface to manage, register, modify avaliable SolrCores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-497) SolrJ QueryResponse does not support date faceting results
SolrJ QueryResponse does not support date faceting results -- Key: SOLR-497 URL: https://issues.apache.org/jira/browse/SOLR-497 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 The QueryResponse provides getFacetFields for drilling down into facets. It would also be handy to have similar info for facet dates. The workaround now is to go through the higher level NamedList -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-334) pluggable query parsers
[ https://issues.apache.org/jira/browse/SOLR-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575459#action_12575459 ] Yonik Seeley commented on SOLR-334: --- So I recently added a nested query parser... it's useful to be able to allow the client to specify query parts but not know about them. So a client could send bf=!query v=$dateboost to add a date boost, but the actual date boost query could be configured as a default on the server: dateboost=!funcrecip(rord(datefield,1,1000,1000)) I'm finding the local params stuff very useful, but I hate the fact that when I type the following URL in firefox, it transforms all the special chars. It makes it very hard to edit (I use a browser a lot for testing). Also, would need to be escaped in any XML config too. Example: I type in http://localhost:8983/solr/select?q=!dismax qf='title^10 body'foo But then firefox transforms it to http://localhost:8983/solr/select?q=%3C!dismax%20qf='title^10%20body'%3Efoo So while things are still changeable (before a release), is this really the right syntax? We could alternately go with [! which doesn't have this problem (and wouldn't have to be escaped in XML config either). So it could look like: http://localhost:8983/solr/select?q=[!dismax qf='title^10 body']foo Which firefox changes to http://localhost:8983/solr/select?q=[!dismax%20qf='title^10%20body']foo Thoughts? pluggable query parsers --- Key: SOLR-334 URL: https://issues.apache.org/jira/browse/SOLR-334 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: qparser.patch, qparser.patch, qparser.patch One should be able to optionally specify an alternate query syntax on a per-query basis http://www.nabble.com/Using-HTTP-Post-for-Queries-tf3039973.html#a8483387 Many benefits, including avoiding the need to do query parser escaping for simple term or prefix queries. Possible Examples: fq=!term field=myfieldThe Term fq=!prefix field=myfieldThe Prefix q=!qp op=ANDa b q=!xml?xml... // lucene XML query syntax? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-497) SolrJ QueryResponse does not support date faceting results
[ https://issues.apache.org/jira/browse/SOLR-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-497: - Description: The QueryResponse provides getFacetFields for drilling down into facets. It would also be handy to have similar info for facet dates. (was: The QueryResponse provides getFacetFields for drilling down into facets. It would also be handy to have similar info for facet dates. The workaround now is to go through the higher level NamedList ) SolrJ QueryResponse does not support date faceting results -- Key: SOLR-497 URL: https://issues.apache.org/jira/browse/SOLR-497 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 The QueryResponse provides getFacetFields for drilling down into facets. It would also be handy to have similar info for facet dates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-343) Constraining date facets by facet.mincount
[ https://issues.apache.org/jira/browse/SOLR-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-343: Assignee: Grant Ingersoll Constraining date facets by facet.mincount -- Key: SOLR-343 URL: https://issues.apache.org/jira/browse/SOLR-343 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.2 Environment: Solr 1.2+ Reporter: Raiko Eckstein Assignee: Grant Ingersoll Priority: Minor Attachments: DateFacetsMincountPatch.patch It would be helpful to allow the facet.mincount parameter to work with date facets, i.e. constraining the results so that it would be possible to filter out date ranges in the results where no documents occur from the server-side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-342. -- Resolution: Fixed Committed revision 634016. Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse) --- Key: SOLR-342 URL: https://issues.apache.org/jira/browse/SOLR-342 Project: Solr Issue Type: Improvement Components: update Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, SOLR-342.patch, SOLR-342.tar.gz LUCENE-843 adds support for new indexing capabilities using the setRAMBufferSizeMB() method that should significantly speed up indexing for many applications. To fix this, we will need trunk version of Lucene (or wait for the next official release of Lucene) Side effect of this is that Lucene's new, faster StandardTokenizer will also be incorporated. Also need to think about how we want to incorporate the new merge scheduling functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-470) DateField throws error on iso8601 date
[ https://issues.apache.org/jira/browse/SOLR-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12575506#action_12575506 ] Hoss Man commented on SOLR-470: --- note: in addition to DateField.toObject(String) (which is used when there is DateMath) DateField.toObject(Fieldable) also has the same bug... http://www.nabble.com/Unparseable-date-td15854401.html DateField throws error on iso8601 date -- Key: SOLR-470 URL: https://issues.apache.org/jira/browse/SOLR-470 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: patrick o'leary Assignee: Hoss Man Fix For: 1.3 A correct iso 8601 date 2006-01-01T12:01:00Z throws an error. Unparseable date: 2006-01-01T12:01:00Z at org.apache.solr.schema.DateField.toObject(DateField.java:173) at org.apache.solr.schema.DateField.toObject(DateField.java:83) The ThreadLocalDateFormat requires fractional seconds -MM-dd'T'HH:mm:ss.SSS to parse with simple date format. Where as the jdoc states their optional. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-386) Add confuguration to specify SolrHighlighter implementation
Thanks to Grant and Mike for the feedback! It is much appreciated. Is there a quick and easy way to check for unnecessary whitespace changes? It isn't that hard for me to go through the patch by hand to find and remove them, but if there is an easier way I'm happy to hear it. I had taken the suggestion that Eli gave somewhat literally and made SolrHighlighter an interface like RequestHandler. In the SolrCore there are three existing objects that are configured: SolrEventListener, SolrRequestHandler, and UpdateHandler. The first two are interfaces and the third is an abstract class. While I'm sure the maintenance concern is legitimate, I'm not sure what the maintenance concern is - could someone elaborate? I'll take your advice and make an AbstractSolrHighlighter that SolrHighlighter (and my custom highlighter) extends. I noticed that some of the other configurable objects implement SolrInfoMBean. Is this something that the SolrHighlighter/AbstractSolrHighlighter should also do? Thanks, Tricia Mike Klaas (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574337#action_12574337 ] Mike Klaas commented on SOLR-386: - Hi Tricia, I'm not sure that I would ever use SolrHighlighter overriding (if I had the need, I probably would just make a separate search component). However, several people want this functionality and it has relatively low implementation/maintenance cost. There are a few things that need to be done to get the patch committed. First, the unnecessary whitespace changes in SolrCore shouldn't be in the diff (it makes it really hard to see the changes, and might make it hard to apply/revert). Also, I'm skeptical of using interfaces for this type of thing, for maintenance reasons. Perhaps we could move to one of the approaches that Grant suggested? Thanks again for the contribution, and sorry it took so long Add confuguration to specify SolrHighlighter implementation --- Key: SOLR-386 URL: https://issues.apache.org/jira/browse/SOLR-386 Project: Solr Issue Type: Improvement Components: highlighter Affects Versions: 1.3 Reporter: Eli Levine Assignee: Mike Klaas Attachments: SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch It would be great if SolrCore allowed the highlighter class to be configurable. A good way would be to add a +class+ attribute to the highlighting element in solrconfig.xml, similar to how the RequestHandler instance is initialized in SorCore.
Re: [jira] Commented: (SOLR-386) Add confuguration to specify SolrHighlighter implementation
Hi Tricia, I don't suggest removing whitespace by hand--the best way to avoid the situation is to make sure that your editor does not automatically edit the whitespace of a file (some good-intentioned editors do this). The maintenance concern with interfaces is that if we want to add a method to the highlighter contract, doing so will break all custom implementors of the interface. If it is an abstract class that must be subclassed, we can add a default implementation to the new method without breaking everyone's code. As for the contract, I was going to review the proposed patch to see what the interface consists of, but I think that all that is required is: .initialize(Config) .isHighlightEnabled(SolrParams) .doHighlighting(...) .getHighlightFields(...) (which is probably what you had in your patch already---JIRA seems down at the moment so I can't check). cheers, -Mike On 5-Mar-08, at 2:49 PM, Tricia Williams wrote: Thanks to Grant and Mike for the feedback! It is much appreciated. Is there a quick and easy way to check for unnecessary whitespace changes? It isn't that hard for me to go through the patch by hand to find and remove them, but if there is an easier way I'm happy to hear it. I had taken the suggestion that Eli gave somewhat literally and made SolrHighlighter an interface like RequestHandler. In the SolrCore there are three existing objects that are configured: SolrEventListener, SolrRequestHandler, and UpdateHandler. The first two are interfaces and the third is an abstract class. While I'm sure the maintenance concern is legitimate, I'm not sure what the maintenance concern is - could someone elaborate? I'll take your advice and make an AbstractSolrHighlighter that SolrHighlighter (and my custom highlighter) extends. I noticed that some of the other configurable objects implement SolrInfoMBean. Is this something that the SolrHighlighter/AbstractSolrHighlighter should also do? Thanks, Tricia Mike Klaas (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574337 #action_12574337 ] Mike Klaas commented on SOLR-386: - Hi Tricia, I'm not sure that I would ever use SolrHighlighter overriding (if I had the need, I probably would just make a separate search component). However, several people want this functionality and it has relatively low implementation/maintenance cost. There are a few things that need to be done to get the patch committed. First, the unnecessary whitespace changes in SolrCore shouldn't be in the diff (it makes it really hard to see the changes, and might make it hard to apply/revert). Also, I'm skeptical of using interfaces for this type of thing, for maintenance reasons. Perhaps we could move to one of the approaches that Grant suggested? Thanks again for the contribution, and sorry it took so long Add confuguration to specify SolrHighlighter implementation --- Key: SOLR-386 URL: https://issues.apache.org/jira/browse/SOLR-386 Project: Solr Issue Type: Improvement Components: highlighter Affects Versions: 1.3 Reporter: Eli Levine Assignee: Mike Klaas Attachments: SOLR-386-SolrHighlighter.patch, SOLR-386- SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, SOLR-386- SolrHighlighter.patch It would be great if SolrCore allowed the highlighter class to be configurable. A good way would be to add a +class+ attribute to the highlighting element in solrconfig.xml, similar to how the RequestHandler instance is initialized in SorCore.
Re: [jira] Commented: (SOLR-386) Add confuguration to specify SolrHighlighter implementation
OK. So I think I fixed the whitespace problem. Thanks for explaining the problem with interfaces -- that makes sense now. I assume that EventListener and RequestHandler are interfaces because they've been thought long and hard about and are not going to change? My first try at the patch was just to include the public methods, which are the ones you list: .initialize(Config) .isHighlightEnabled(SolrParams) .doHighlighting(...) .getHighlightFields(...) I discovered that the unit tests call the formatters and fragmenters directly so in the interface version I made public get methods for these. Now that we're using an abstract class I am able to just include these as is - so no changes to HighlighterTest this time. But speaking of unit tests... Anecdotally I know that the SolrCore changes allow the highlighter to be configured (my custom highlighter). I guess I should write a unit test that ensures this works. I'll do that now. After doing some thinking I decided to leave the default implementation of isHighlightingEnabled(SolrParams), and getHighlightFields(...) in the abstract class because both methods deal with reading parameters. I can't think of a use case of a highlighter that wouldn't use this or at worst ignore/override this method. Is this a reasonable decision? I wasn't sure what to do with the logger, so I left it in the AbstractSolrHighlighter. Thoughts? Tricia p.s. I've attached the updated patch since JIRA appears to be down. Mike Klaas wrote: Hi Tricia, I don't suggest removing whitespace by hand--the best way to avoid the situation is to make sure that your editor does not automatically edit the whitespace of a file (some good-intentioned editors do this). The maintenance concern with interfaces is that if we want to add a method to the highlighter contract, doing so will break all custom implementors of the interface. If it is an abstract class that must be subclassed, we can add a default implementation to the new method without breaking everyone's code. As for the contract, I was going to review the proposed patch to see what the interface consists of, but I think that all that is required is: .initialize(Config) .isHighlightEnabled(SolrParams) .doHighlighting(...) .getHighlightFields(...) (which is probably what you had in your patch already---JIRA seems down at the moment so I can't check). cheers, -Mike On 5-Mar-08, at 2:49 PM, Tricia Williams wrote: Thanks to Grant and Mike for the feedback! It is much appreciated. Is there a quick and easy way to check for unnecessary whitespace changes? It isn't that hard for me to go through the patch by hand to find and remove them, but if there is an easier way I'm happy to hear it. I had taken the suggestion that Eli gave somewhat literally and made SolrHighlighter an interface like RequestHandler. In the SolrCore there are three existing objects that are configured: SolrEventListener, SolrRequestHandler, and UpdateHandler. The first two are interfaces and the third is an abstract class. While I'm sure the maintenance concern is legitimate, I'm not sure what the maintenance concern is - could someone elaborate? I'll take your advice and make an AbstractSolrHighlighter that SolrHighlighter (and my custom highlighter) extends. I noticed that some of the other configurable objects implement SolrInfoMBean. Is this something that the SolrHighlighter/AbstractSolrHighlighter should also do? Thanks, Tricia Mike Klaas (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574337#action_12574337 ] Mike Klaas commented on SOLR-386: - Hi Tricia, I'm not sure that I would ever use SolrHighlighter overriding (if I had the need, I probably would just make a separate search component). However, several people want this functionality and it has relatively low implementation/maintenance cost. There are a few things that need to be done to get the patch committed. First, the unnecessary whitespace changes in SolrCore shouldn't be in the diff (it makes it really hard to see the changes, and might make it hard to apply/revert). Also, I'm skeptical of using interfaces for this type of thing, for maintenance reasons. Perhaps we could move to one of the approaches that Grant suggested? Thanks again for the contribution, and sorry it took so long Add confuguration to specify SolrHighlighter implementation --- Key: SOLR-386 URL: https://issues.apache.org/jira/browse/SOLR-386 Project: Solr Issue Type: Improvement Components: highlighter Affects Versions: 1.3 Reporter: Eli Levine Assignee: Mike Klaas Attachments: SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch,
[jira] Resolved: (SOLR-496) Expires HTTP header not set correctly
[
https://issues.apache.org/jira/browse/SOLR-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-496.
---
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Hoss Man
thanx for catching this Thomas.
Committed revision 634072.
Expires HTTP header not set correctly
-
Key: SOLR-496
URL: https://issues.apache.org/jira/browse/SOLR-496
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.3
Reporter: Thomas Peuss
Assignee: Hoss Man
Fix For: 1.3
Attachments: SOLR-496.patch
I am testing the code from SOLR-127. I have seen following behaviour for the
_Expires_ HTTP header.
Solr-config:
{noformat}
httpCaching lastModFrom=dirLastMod etagSeed=IBX20080304
cacheControlmax-age=2419200/cacheControl
/httpCaching
{noformat}
Generated HTTP-headers:
HTTP/1.x 200 OK
Server: Apache-Coyote/1.1
Cache-Control: max-age=2419200
*Expires: Mon, 11 Feb 2008 15:24:49 GMT*
Last-Modified: Fri, 29 Feb 2008 14:25:07 GMT
Etag: NmVmZmNiYzdjODgwMDAwMElCWDIwMDgwMzA0
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
*Date: Tue, 04 Mar 2008 08:27:36 GMT*
We are going back in time. max-age=2419200 is 4 weeks in seconds. I checked
the code and I have not found anything that could trigger that behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-386) Add confuguration to specify SolrHighlighter implementation
[ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tricia Williams updated SOLR-386: - Attachment: SOLR-386-SolrHighlighter.patch OK. So I think I fixed the whitespace problem. Thanks for explaining the problem with interfaces -- that makes sense now. I assume that EventListener and RequestHandler are interfaces because they've been thought long and hard about and are not going to change? My first try at the patch was just to include the public methods, which are the ones you (MIke Klaas) list: .initialize(Config) .isHighlightEnabled(SolrParams) .doHighlighting(...) .getHighlightFields(...) I discovered that the unit tests call the formatters and fragmenters directly so in the interface version I had made public get methods for these. Now that we're using an abstract class I am able to just include these as is - so no changes to HighlighterTest this time. But speaking of unit tests... Anecdotally I know that the SolrCore changes allow the highlighter to be configured (my custom highlighter). I wrote HighlighterConfigTest as a unit test for this functionality. I decided to leave the default implementation of isHighlightingEnabled(SolrParams), and getHighlightFields(...) in the abstract class because both methods deal with reading parameters. I can't think of a use case of a highlighter that wouldn't use this or at worst ignore/override this method. Is this a reasonable decision? I wasn't sure what to do with the logger, so I left it in the AbstractSolrHighlighter. This decision is based on the example of UpdateHandler. Hmm... I just realized that naming the abstraction of SolrHighlighter AbstractSolrHighlighter causes problems all over the code when you want your custom highlighter to plugin. I think the path of least resistance is to call the abstract class SolrHighlighter and the existing implementation DefaultSolrHighlighter. Thoughts? Add confuguration to specify SolrHighlighter implementation --- Key: SOLR-386 URL: https://issues.apache.org/jira/browse/SOLR-386 Project: Solr Issue Type: Improvement Components: highlighter Affects Versions: 1.3 Reporter: Eli Levine Assignee: Mike Klaas Attachments: SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch It would be great if SolrCore allowed the highlighter class to be configurable. A good way would be to add a +class+ attribute to the highlighting element in solrconfig.xml, similar to how the RequestHandler instance is initialized in SorCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
