[jira] Updated: (SOLR-244) ModifiableSolrParams -- (perhaps) modify MultiMapSolrParams
[
https://issues.apache.org/jira/browse/SOLR-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-244:
---
Attachment: SOLR-244-ModifiableSolrParams.patch
This includes a new class (with tests) and augments MultiMapSolrParams with
set() and add()
Only one of the changes should be included -- unless there is a good reason
*not* to augment MultiMapSolrParams, I think that is a better solution.
I know all of this is possible with the existing interface, but I prefer:
MultiMapSolrParams params = new MultiMapSolrParams();
params.add( "name", "value1" );
...
params.set( "name", "value2", "value3" );
to:
Map map = new HashMap();
MultiMapSolrParams params = new MultiMapSolrParams( map );
MultiMapSolrParams.addParam( "name", "value1", map );
...
map.put( "name", new String[] { "value2", "value3" } );
> ModifiableSolrParams -- (perhaps) modify MultiMapSolrParams
> ---
>
> Key: SOLR-244
> URL: https://issues.apache.org/jira/browse/SOLR-244
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-244-ModifiableSolrParams.patch
>
>
> The existing ways to change parameters at runtime are awkward, this is a
> class I have been using in SOLR-20. It is a solr params implementation with
> two nice additions:
> public void set( String name, String ... val ) {
>...
> }
> public void add( String name, String ... val ) {
> ...
> }
> Rather then have a new class, it may be better to augment MultiMapSolrParams
> to include a default constructor and use set/add to modify the final
> Map
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-244) ModifiableSolrParams -- (perhaps) modify MultiMapSolrParams
ModifiableSolrParams -- (perhaps) modify MultiMapSolrParams
---
Key: SOLR-244
URL: https://issues.apache.org/jira/browse/SOLR-244
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Priority: Minor
The existing ways to change parameters at runtime are awkward, this is a class
I have been using in SOLR-20. It is a solr params implementation with two nice
additions:
public void set( String name, String ... val ) {
...
}
public void add( String name, String ... val ) {
...
}
Rather then have a new class, it may be better to augment MultiMapSolrParams to
include a default constructor and use set/add to modify the final
Map
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-208) RSS feed XSL example
[
https://issues.apache.org/jira/browse/SOLR-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497684
]
Ryan McKinley commented on SOLR-208:
As an example, I don't think it matters if this is RSS, Atom, or GData. It
just needs to show that you *can* transform solr results into a "standard"
syndication format.
Any real example would need to change the specifics dramatically (unless you
really wanted the description to be a list of "features" and link to
http://localhost:8983/solr/select?q=id:${id})
As hoss suggests, I think this is good to include as long as the comments make
it clear that you need to change stuff to make it 'real' - this may include
reformatting to atom or gdata...
> RSS feed XSL example
>
>
> Key: SOLR-208
> URL: https://issues.apache.org/jira/browse/SOLR-208
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.2
>Reporter: Brian Whitman
> Assigned To: Hoss Man
>Priority: Trivial
> Attachments: rss.xsl
>
>
> A quick .xsl file for transforming solr queries into RSS feeds. To get the
> date and time in properly you'll need an XSL 2.0 processor, as in
> http://wiki.apache.org/solr/XsltResponseWriter . Tested to work with the
> example solr distribution in the nightly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Luke request handler issue
If Ryan is date-less again tonight, I'm sure he'll have it all fixed up by the time I wake up :) Otherwise, I'll dig in and roll up my sleeves sometime this week and make some adjustments to allow turning off the top terms feature. Just back from a week of nothing that goes beep... it was great! Now my girlfriend has to study for the bar, so i will have more time ;) Perhaps numTerms=0 would skip all term collecting... also, it may be worth caching the top terms, but i don't really want to go there just yet. Yonik suggested numTerms should be specified per field. This is easy enough... Did you get a chance to look at the code? or should i add the numTerms=0 behavior? ryan
Re: Spellchecker in production environment
Actually one correction to this. I made a separate jar with these changes and dropped it in the solr lib/ dir. The base jar is unmodified. -- Adam On May 21, 2007, at 2:48 PM, Adam Hiatt wrote: I happen to be using a backported version in my live code: http:// www.cnet.com/4244-5_1-0.html?query=ipid&tag=srch&target=nw This is SOLR 1.1 w/ patches. There are no deps on 1.2ish stuff. BTW, the UI is somewhat confusing, we're changing that soon. -- Adam On May 21, 2007, at 2:20 PM, fstauffer wrote: Hello, I am currently working on a project that is uses the 1.1 solr release for its search engine (using a php interface). We are about to deploy this project in a production environment and we would like to include Spellchecker support as well. I managed to get the spellchecker request handler to work with a nightly build, which triggered a few questions: - would it be better in a production environment to "backport" the spellchecker functionality in the 1.1 release (I am not sure how deep the spellchecker impacts other parts of solr)? - or should I wait for the 1.2 release (no idea about the timeframe)? - or should I keep on using nightly builds? Thanks a lot for your answers or opinions, Franck -- View this message in context: http://www.nabble.com/Spellchecker- in-production-environment-tf3792904.html#a10727310 Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: Spellchecker in production environment
Or just listen to yonik... -- Adam On May 21, 2007, at 2:25 PM, Yonik Seeley wrote: On 5/21/07, fstauffer <[EMAIL PROTECTED]> wrote: - or should I wait for the 1.2 release (no idea about the timeframe)? This month! - or should I keep on using nightly builds? Yes, until 1.2 is out. -Yonik
Re: Spellchecker in production environment
I happen to be using a backported version in my live code: http:// www.cnet.com/4244-5_1-0.html?query=ipid&tag=srch&target=nw This is SOLR 1.1 w/ patches. There are no deps on 1.2ish stuff. BTW, the UI is somewhat confusing, we're changing that soon. -- Adam On May 21, 2007, at 2:20 PM, fstauffer wrote: Hello, I am currently working on a project that is uses the 1.1 solr release for its search engine (using a php interface). We are about to deploy this project in a production environment and we would like to include Spellchecker support as well. I managed to get the spellchecker request handler to work with a nightly build, which triggered a few questions: - would it be better in a production environment to "backport" the spellchecker functionality in the 1.1 release (I am not sure how deep the spellchecker impacts other parts of solr)? - or should I wait for the 1.2 release (no idea about the timeframe)? - or should I keep on using nightly builds? Thanks a lot for your answers or opinions, Franck -- View this message in context: http://www.nabble.com/Spellchecker-in- production-environment-tf3792904.html#a10727310 Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: Spellchecker in production environment
On 5/21/07, fstauffer <[EMAIL PROTECTED]> wrote: - or should I wait for the 1.2 release (no idea about the timeframe)? This month! - or should I keep on using nightly builds? Yes, until 1.2 is out. -Yonik
Spellchecker in production environment
Hello, I am currently working on a project that is uses the 1.1 solr release for its search engine (using a php interface). We are about to deploy this project in a production environment and we would like to include Spellchecker support as well. I managed to get the spellchecker request handler to work with a nightly build, which triggered a few questions: - would it be better in a production environment to "backport" the spellchecker functionality in the 1.1 release (I am not sure how deep the spellchecker impacts other parts of solr)? - or should I wait for the 1.2 release (no idea about the timeframe)? - or should I keep on using nightly builds? Thanks a lot for your answers or opinions, Franck -- View this message in context: http://www.nabble.com/Spellchecker-in-production-environment-tf3792904.html#a10727310 Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Closed: (SOLR-199) N-gram
[ https://issues.apache.org/jira/browse/SOLR-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley closed SOLR-199. - Resolution: Fixed Thanks Adam, I just committed this. > N-gram > -- > > Key: SOLR-199 > URL: https://issues.apache.org/jira/browse/SOLR-199 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Adam Hiatt >Priority: Trivial > Attachments: SOLR-199-n-gram.patch, SOLR-81-ngram.patch > > > This tracks the creation of a patch that adds the n-gram/edge n-gram > tokenizing functionality that was initially part of SOLR-81 (spell checking). > This was taken out b/c the lucene SpellChecker class removed this dependency. > None-the-less, I think this is useful functionality and the addition is > trivial. How does everyone feel about such an addition? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-Nightly #88
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/88/
