Re: Code style
: thinking might be useful (in Lucene as well) is to have downloadable : codestyle templates for IntelliJ and Eclipse defined and linked to : from the developer section of the website (or it could even be I certainly have no objection to hosting any style files for any editors people like on the wiki, or even in SVN, as long as it's clear these are just "aids" for people who want help being more consistent, and not indications that the use of certain editors/IDEs to ensure consistent code are mandatory for submitting patches or commiting changes. -Hoss
[jira] Commented: (SOLR-242) tr parameter implies XSL, no wt=xslt necessary
[ https://issues.apache.org/jira/browse/SOLR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497089 ] Hoss Man commented on SOLR-242: --- this would go against the current model in Solr, that SolrCore (or the now the dispatcher) looks at as few options as necessary to hand off to a request handler, and based onteh result then to an outputwriter ... this would make it necessary for SolrCore to know about properties specific to a single OutputWriter ... saying that the presence of "tr" means use the XsltResponseWriter is like saying that if the "json.nl" param is specified, and a "wt" is not specified, then assume "wt=json" ... it starts crossing a scary line. there's also no requirement that clients register the XsltResponseWriter, and custom request handlers might have a different use for a param named 'tr" I'm also not sure i understand your last comment... "Imagine in the future there's a response writer that outputs a different kind of XML. That shouldn't preclude the use of a transform on top of that response." ...true, but you would need differnet XSLTs for differnet base XML responses, and the current XsltResponseWriter forcably uses the XmlResponseWriter to get it's input .. if someone wanted to style some other hypothetical future xml format, then the XsltResponseWriter would need to know about that class -- either hardcoded in it, or more likely as an init param .. in which case you'd wnat to register multiple instances of hte Writer using different names ... how would you know which one to use given only the "tr" param? > tr parameter implies XSL, no wt=xslt necessary > -- > > Key: SOLR-242 > URL: https://issues.apache.org/jira/browse/SOLR-242 > Project: Solr > Issue Type: Improvement >Reporter: Brian Whitman >Priority: Trivial > > Perhaps the most trivial issue ever, but &tr=file.xsl should imply that the > XML from whichever response writer is being used gets parsed by the given > transform. The wt=xslt is somewhat redundant. And maybe change the tr > parameter to xslt. > Imagine in the future there's a response writer that outputs a different kind > of XML. That shouldn't preclude the use of a transform on top of that > response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-242) tr parameter implies XSL, no wt=xslt necessary
tr parameter implies XSL, no wt=xslt necessary -- Key: SOLR-242 URL: https://issues.apache.org/jira/browse/SOLR-242 Project: Solr Issue Type: Improvement Reporter: Brian Whitman Priority: Trivial Perhaps the most trivial issue ever, but &tr=file.xsl should imply that the XML from whichever response writer is being used gets parsed by the given transform. The wt=xslt is somewhat redundant. And maybe change the tr parameter to xslt. Imagine in the future there's a response writer that outputs a different kind of XML. That shouldn't preclude the use of a transform on top of that response. -- 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
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497069 ] Brian Whitman commented on SOLR-69: --- Oof ryan, my apologies, I was running an older version of this patch. fl is listened to. This is an excellent job, btw, I love that you can hide the original response. > 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.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.
[jira] Commented: (SOLR-69) PATCH:MoreLikeThis support
[ https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497022 ] Brian Whitman commented on SOLR-69: --- Ryan, it seems the handler doesn't listen to the fl parameter either in the result section or the morelikethis section. It always returns everything. > 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.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.
Re: Code style
One thing I just saw on the Maven developer [1] section that I was thinking might be useful (in Lucene as well) is to have downloadable codestyle templates for IntelliJ and Eclipse defined and linked to from the developer section of the website (or it could even be checked out w/ the code). I have a Lucene one for IntelliJ that I use, but I am not sure it captures our style 100%, but I would be willing to post it and others can fix it up. Granted, it doesn't completely solve the problem as people still need to know it is there and use it, but at least it puts out a concrete example of what the code style should be and one could do a friendly nag every now and then for people to use it. Just a thought, Grant [1] See further down on http://maven.apache.org/guides/development/ guide-m2-development.html On May 17, 2007, at 2:56 PM, Otis Gospodnetic wrote: Hi, - Original Message From: Chris Hostetter <[EMAIL PROTECTED]> I'd certianly prefer if all new code and new changes met teh style guidelines we have setup -- tidying up the lines that are being changed anyway as part of the commit, but frankly i'd just as soon leave code that works but isn't super pretty well enough alone. OG: That would be ideal. However, sometimes you want to work on the existing code and the hard-to-parse style makes it harder for you to follow and understand the code. I'm facing that now with SolrIndexSearcher, which is what promoted this thread. Otis
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496805 ] Emmanuel Keller commented on SOLR-236: -- You're right. As collapse.field is a required field, we don't need more information. My first idea was to copy the behavior of facet. > 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.2 >Reporter: Emmanuel Keller > Attachments: collapse_field.patch, collapse_field.patch, > field_collapsing.patch, field_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=48&amid=299 > The implementation add 4 new query parameters (SolrParams): > "collapse" set to true to enable collapsing. > "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 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
