[jira] Updated: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-176: -- Attachment: RequesthandlerBase.patch added some average stats to RequestHandlerBase. all of the same info can be obtained by parsing the log files but having it show up on the admin screens and jmx is simple and nice to have. stats added: avgTimePerRequest and avgRequestsPerSecond. > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas > Assigned To: Mike Klaas >Priority: Minor > Fix For: 1.2 > > Attachments: dtiming.patch, dtiming.patch, RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496606 ] Otis Gospodnetic commented on SOLR-239: --- Minor comment: if you use the same name for the patch file, JIRA will automatically gray out the older one, thus making it easier to spot which patches are out of date, and which one is the fresh one to look at. Thanks for the patch, this sounds useful. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- 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_12496607 ] Otis Gospodnetic commented on SOLR-208: --- +1 for including this. I imagine a lot of people will want this to provide "subscribe to search results for a saved search" type functionality. > 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.
[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_12496608 ] Walter Underwood commented on SOLR-208: --- What kind of RSS? -1 unless it is Atom. The nine variants of RSS have some nasty interop problems, even between those that are supposed to implement the same spec. Even better, a GData interface returning Atom. > 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.
[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_12496612 ] Brian Whitman commented on SOLR-208: I'm not involved or familiar with the RSS wars but I will say that this is a quick example of getting RSS out of Solr in the easiest possible way. It worked on every single browser and newsreader I tried it on. There's no reason we can't also include an atom_example.xsl as well. I don't understand why you would use GData for this at all, but i am probably out of my league there. +1 for adding except remove the XSL2.0 references, not worth the confusion, date handling is not necessary for the exampledocs test case. > 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.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496617 ] Otis Gospodnetic commented on SOLR-236: --- Question: Do you need collapse=true when you can detect whether collapse.field has been specified or not? > 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.
[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_12496624 ] Walter Underwood commented on SOLR-208: --- I wasn't in the RSS wars, either, but I was on the Atom working group. That was a bunch of volunteers making a clean, testable spec for RSS functionality (http://www.ietf.org/rfc/rfc4287). RSS 2.0 has some bad ambiguities, especially around ampersand and entities in titles. The default has changed over the years and clients do different, incompatible things. GData is just a way to do search result stuff that we would need anyway. It is standard set of URL parameters for query, start-index, and categories, and a few Atom extensions for total results, items per page, and next/previous. http://code.google.com/apis/gdata/reference.html > 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.
Code style
Hi, Touchy topic: code style Should Solr be following the Lucene code formatting/style? Lucene follows Sun's recommendation except for the 2-space indent, I believe. I'm asking because Solr is full of variable and method names that look like abbrevs ;) - e.g. getDocListC - "C"?, and on top of that the code is rather dense,without,many,spaces, so it's hard to read, at least for me. Over the years I must have learned to deal with a bunch of other stylistic differences, but the code density is still hard, I find. Sparse braincells? How do the rest of you feel? I volunteer to tidy up the code, if others agree with following Lucene's formating. I believe Nutch and Hadoop already follow it. Thanks, Otis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simpy -- http://www.simpy.com/ - Tag - Search - Share
[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_12496649 ] Otis Gospodnetic commented on SOLR-208: --- Plus there is contrib/gdata-server under Lucene waiting to be used, so there already is gData-something in Luceneland. > 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: Code style
On 5/17/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: Touchy topic: code style Uh, oh... something everyone will have an opinion about ;-) Should Solr be following the Lucene code formatting/style? Lucene follows Sun's recommendation except for the 2-space indent, I believe. Well, that's the general guidelines... there is a ton of lucene code that doesn't follow that though. One "violation" repeated everywhere is if (foo) bar(); Those don't bother me personally, I'm just pointing it out. I'm asking because Solr is full of variable and method names that look like abbrevs ;) - e.g. getDocListC - "C"? Heh... I never realized abbreviations were off-limits. In this particular case, I needed to refactor getDocList into a caching version and a non caching version (C) and (NC). , and on top of that the code is rather dense,without,many,spaces, so it's hard to read, at least for me. Spaces between lines, or spaces in a single line? I tend to compress code where the logic is easy to understand... sometimes spreading simple things out make it harder to see everything in context. How do the rest of you feel? I volunteer to tidy up the code, if others agree with following Lucene's formating. I believe Nutch and Hadoop already follow it. Solr already has a policy that is the same as Lucene. I'm fine with cleanups... just try to avoid breaking patches in JIRA. -Yonik
Re: Code style
: > How do the rest of you feel? I volunteer to tidy up the code, if : > others agree with following Lucene's formating. I believe Nutch and : > Hadoop already follow it. : : Solr already has a policy that is the same as Lucene. : I'm fine with cleanups... just try to avoid breaking patches in JIRA. Once upon a time i thought the idea of cleaning up the formatting of code in commits that *only* changed formatting was a good idea ... but even if hte message is clear that it's just a formatting commit, it still creates noise, makes some patches harder to apply, and moves line numbers arround reducing the number of situations where you can make educated guessees about what went wrongwhen looking at a stack trace from someone without knowing exactly which version they were using. 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. -Hoss
Re: Code style
Hi, - Original Message From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-dev@lucene.apache.org Sent: Thursday, May 17, 2007 2:05:41 PM Subject: Re: Code style On 5/17/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: > Should Solr be following the Lucene code formatting/style? Lucene follows > Sun's recommendation except for the 2-space indent, I believe. Well, that's the general guidelines... there is a ton of lucene code that doesn't follow that though. One "violation" repeated everywhere is if (foo) bar(); Those don't bother me personally, I'm just pointing it out. OG: yes, that's one of those things my brain must have learned to read easily either way. What's missing here? Curly braces? > I'm asking because Solr is full of variable and method names that look like > abbrevs ;) > - e.g. getDocListC - "C"? Heh... I never realized abbreviations were off-limits. In this particular case, I needed to refactor getDocList into a caching version and a non caching version (C) and (NC). OG: Si, I realized that as I read the core more, but it wasn't obvious to me immediately. How quickly things become obvious is important, I think. >, and on top of that the code is rather dense,without,many,spaces, so it's hard to read, at least for me. Spaces between lines, or spaces in a single line? OG: Heh, good question. Again, spaces or not between lines are easy for me, it's the lack of spaces in a single line that make things hard to read-kind of like"things should be made as simple as possible, but not any simpler."-A.Einstein would be hard to read. Mental token parsing - WhiteSpaceBrainTokenizer, I guess. I tend to compress code where the logic is easy to understand... sometimes spreading simple things out make it harder to see everything in context. OG: I agree. This made me learn to appreciate vertically tight code sometimes. > How do the rest of you feel? I volunteer to tidy up the code, if others > agree with following Lucene's formating. I believe Nutch and Hadoop already > follow it. Solr already has a policy that is the same as Lucene. I'm fine with cleanups... just try to avoid breaking patches in JIRA. OG: Right. Right to what Hoss said in his reply, too. OG: Luckily, man patch shows "-l or --ignore-whitespace", which might help. Otis
Re: Code style
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-230) make post.jar support better args for using tutorial
[ https://issues.apache.org/jira/browse/SOLR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496669 ] Carsten commented on SOLR-230: -- Being from the unix fraction: Why is there a need for "-Ddata=stdin" ? Just make it read from stdin if no arguments are given. Good old unix tradition. And by the way: Why would you use system properties to pass parameters instead of simply using a parameter like java -jar post.jar -url http://localhost:8983/solr/update *.xml java -jar post.jar -data "name:DDR" Just my EUR 0.02. > make post.jar support better args for using tutorial > > > Key: SOLR-230 > URL: https://issues.apache.org/jira/browse/SOLR-230 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Hoss Man > Assigned To: Hoss Man > Attachments: SOLR-230.patch > > > SOLR-86 create post.jar which eliminated the need for post.sh ... but as > noticed in > SOLR-164 there are still some cases in the tutorial that require direct use > of curl (deleting) and there are some nice things about post.sh that post.jar > doesn't support (defaulting the URL) > this issue is to tackle some of the ideas Bertrand and I posted as a comment > in SOLR-86 after it was resolved > Bertrand Delacretaz [19/Feb/07 12:35 AM] ... > Considering the tutorial examples > (http://lucene.apache.org/solr/tutorial.html), it'd be useful to allow this > to POST its standard input, or the contents of a command-line parameter: ... > Hoss Man [19/Feb/07 11:50 AM] > yeah ... i think we should hardcode http://localhost:8983/solr/update with a > possible override by system prop, then add either a command line switch other > another system prop indicating to use the command line as filenames or as raw > data, and another op for stdin. > java -jar -Ddata=files post.jar *.xml > java -jar post.jar *.xml ... data=files being the default > echo "name:DDR" | java -jar -Ddata=stdin > post.jar > cat *.xml | java -jar -Ddata=stdin post.jar > java -jar -Ddata=args post.jar "name:DDR" > java -jar -Durl=http://localhost:8983/solr/update post.jar *.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-230) make post.jar support better args for using tutorial
[ https://issues.apache.org/jira/browse/SOLR-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496674 ] Hoss Man commented on SOLR-230: --- To answer both questions: i did it that way just to try and keep the code simple and explicit. i figured using system props would help make the execution examples in the tutorial self documenting, while keeping the simple uses cases very simple, and eliminating the need for any complex getopt style argv parsing. > make post.jar support better args for using tutorial > > > Key: SOLR-230 > URL: https://issues.apache.org/jira/browse/SOLR-230 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Hoss Man > Assigned To: Hoss Man > Attachments: SOLR-230.patch > > > SOLR-86 create post.jar which eliminated the need for post.sh ... but as > noticed in > SOLR-164 there are still some cases in the tutorial that require direct use > of curl (deleting) and there are some nice things about post.sh that post.jar > doesn't support (defaulting the URL) > this issue is to tackle some of the ideas Bertrand and I posted as a comment > in SOLR-86 after it was resolved > Bertrand Delacretaz [19/Feb/07 12:35 AM] ... > Considering the tutorial examples > (http://lucene.apache.org/solr/tutorial.html), it'd be useful to allow this > to POST its standard input, or the contents of a command-line parameter: ... > Hoss Man [19/Feb/07 11:50 AM] > yeah ... i think we should hardcode http://localhost:8983/solr/update with a > possible override by system prop, then add either a command line switch other > another system prop indicating to use the command line as filenames or as raw > data, and another op for stdin. > java -jar -Ddata=files post.jar *.xml > java -jar post.jar *.xml ... data=files being the default > echo "name:DDR" | java -jar -Ddata=stdin > post.jar > cat *.xml | java -jar -Ddata=stdin post.jar > java -jar -Ddata=args post.jar "name:DDR" > java -jar -Durl=http://localhost:8983/solr/update post.jar *.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
