Re: svn commit: r829663 - in /lucene/solr/trunk: site/tutorial.html site/tutorial.pdf src/site/src/documentation/content/xdocs/tutorial.xml
Whoa ... Typos are nothing new to the Solr documentation, but i think this is the first time I've been the one to notice a type in something someone else wrote... : +We can facet multile ways at the same time. The following example adds in a facet on the Also, the URLs in the highlighting faceting sections are a little confusing... : +a href=http://localhost:8983/solr/select/?wt=jsonamp;indent=onamp;q=*:*amp;fl=nameamp;facet=trueamp;facet.field=catamp;facet.field=inStock;q=*:*amp;facet=trueamp;facet.field=catamp;facet.field=inStock/a ...the href's all contain wt=jsonindent=on but the visible text doesn't, which makes it kind of suprising when you click on them since all the previous examples have produced an XML response (except for one which has wt=json in the text and explicit says (return response in JSON format) next to it. If people think the json output is easier to read, then i'm cool with using it, but the link text should match the link href. -Hoss
Re: svn commit: r829663 - in /lucene/solr/trunk: site/tutorial.html site/tutorial.pdf src/site/src/documentation/content/xdocs/tutorial.xml
On Mon, Oct 26, 2009 at 2:33 AM, Chris Hostetter hossman_luc...@fucit.org wrote: Whoa ... Typos are nothing new to the Solr documentation, but i think this is the first time I've been the one to notice a type in something someone else wrote... : + We can facet multile ways at the same time. The following example adds in a facet on the Heh... I had even spell-checked it... but that still requires a visual scan for misspellings :-) Also, the URLs in the highlighting faceting sections are a little confusing... : + a href=http://localhost:8983/solr/select/?wt=jsonamp;indent=onamp;q=*:*amp;fl=nameamp;facet=trueamp;facet.field=catamp;facet.field=inStock;q=*:*amp;facet=trueamp;facet.field=catamp;facet.field=inStock/a ...the href's all contain wt=jsonindent=on but the visible text doesn't, which makes it kind of suprising when you click on them since all the previous examples have produced an XML response These are realy URL fragments... none of the other examples show the indent=on or the rest of the URL either, and when we get down to faceting, the fl is also hidden. Showing all of the parameters would serve to obscure the important ones that are pertinent to the section. Surprising, yes... but not in a bad way I think. It's not the type of API surprise that causes bugs, and it should be immediately obvious when they look at the URL. (except for one which has wt=json in the text and explicit says (return response in JSON format) next to it. As you point out, the wt=json parameter was explicitly presented earlier, so it seems fair game for not calling it out explicitly. If people think the json output is easier to read, then i'm cool with using it, but the link text should match the link href. JSON prevents highlighter markup from being escaped... didn't want anyone seeing lt;emgt; The other benefit is vertical size - the XML format often consumed enough that the extra response info (highlighting or faceting) was pushed completely off the page, and would require the user to scroll down to see the start of it. -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-64) strict hierarchical facets
[
https://issues.apache.org/jira/browse/SOLR-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770027#action_12770027
]
Lesiak Rémy commented on SOLR-64:
-
Hi all,
I use the the Solr version 1.4-dev.
I want to apply this patch, but I have an error on the class SimpleFacet during
the patch.
I have apply the patch manually. After I want reproduce the example of this
page, but I obtained this result :
facet_counts:{
facet_queries:{},
facet_fields:{
hiefacet_h:[
sub_facets,[
A,1,
path-A,A/,
sub_facets,[
B,1,
path-B,A/B/,
sub_facets,[
E,1,
path-E,A/B/E/,
sub_facets,[
B,1,
path-B,A/B/E/B/,
sub_facets,[
B,1,
path-B,A/B/E/B/B/,
sub_facets,[
D,1,
path-D,A/B/E/B/B/D/,
sub_facets,[
E,1,
path-E,A/B/E/B/B/D/E/,
sub_facets,[
A,1,
path-A,A/B/E/B/B/D/E/A/,
sub_facets,[
B,1,
path-B,A/B/E/B/B/D/E/A/B/,
sub_facets,[
E,1,
path-E,A/B/E/B/B/D/E/A/B/E/,
sub_facets,[
A,1,
path-A,A/B/E/B/B/D/E/A/B/E/A/,
sub_facets,[
etc
strict hierarchical facets
--
Key: SOLR-64
URL: https://issues.apache.org/jira/browse/SOLR-64
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Yonik Seeley
Fix For: 1.5
Attachments: SOLR-64.patch, SOLR-64.patch
Strict Facet Hierarchies... each tag has at most one parent (a tree).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Another RC
Will do once I have a Lucene RC. On Oct 25, 2009, at 3:59 PM, Yonik Seeley wrote: If all goes well in lucene-land 2.9.1 should start a vote on Monday sometime... I've recently tested the latest stable Jetty (6.1.21) ... so we can avoid some duplication, has anyone tested with the latest tomcat, resin, or other popular servlet containers? -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 5:57 PM, Yonik Seeley yo...@lucidimagination.com wrote: OK, so let's do the following: as soon as the Lucene 2.9.1 official RC is put up (the one that will be voted on), I'll update Solr and we can do our vote at the same time, saving 3 or 4 days... this release has really been held up long enough :-) We can re-evaluate what to do if for some reason the Lucene vote doesn't pass (i.e., we won't blindly release Solr if the lucene vote fails). Hopefully everyone has looked at the latest Solr distributions for any potential showstoppers that would cause them to vote -1 during the official vote. -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood wun...@wunderwood.org wrote: Please wait for an official release of Lucene. It makes thing SO much easier when you need to dig into the Lucene code. It is well worth a week delay. wunder On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote: On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll gsing...@apache.org wrote: Are we ready for a release? +1 I don't think we need to wait for Lucene 2.9.1 - we have all the fixes in our version, and there's little point in pushing things off yet another week. Seems like the next RC should be a *real* one (i.e. no RC label in the version, immediately call a VOTE). -Yonik http://www.lucidimagination.com I got busy at work and haven't been able to address things as much, but it seems like things are progressing. Shall I generate another RC or are we waiting for Lucene 2.9.1? If we go w/ the 2.9.1-dev, then we just need to restore the Maven stuff for them. Hopefully, that stuff was just commented out and not completely removed so as to make it a little easier to restore. -Grant -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Re: svn commit: r829663 - in /lucene/solr/trunk: site/tutorial.html site/tutorial.pdf src/site/src/documentation/content/xdocs/tutorial.xml
: These are realy URL fragments... none of the other examples show the : indent=on or the rest of the URL either, and when we get down to indent=on doesn't really affect the structure of the response docs (especially since people following the tutorial are likely to be using a browser that pretty prints the XML) ... if you set indent aside, all of the demo links in the previous versions of the tutorial were either... 1) full URLs (starting with http://...) 2) SolrQuerySyntax (w/o any url escaping or metacharacters) when the text arround them made it clear they were query sytnax examples not URL fragments 3) full /select URL query parts (ie: everything after the ?) ...the new sections you've added (highlighting faceting) *look* like they are type#3, expcet that they leave out params that change the functionality. If the link text left out *all* params except the ones being showcased and contained elipses or soemthing to indicate that they were partial... THIS: ...hl=truehl.fl=name,features INSTEAD OF: q=video cardfl=name,idhl=truehl.fl=name,features ...then it would probably be less confusing when other params besides the ones in the link text were acctually used in the link href (and would draw attention to the fact that we are building off of other params already seen) : faceting, the fl is also hidden. Showing all of the parameters i missed that you added that fl there as well (the json formating made it less obvious when looking at the result page) but it's just another example of my point. Ultimately my concern is just that we try to be consistent with our exmaple URLs, and your point about indent illustrates that we weren't really that good about it before, but let's try to be at least as good as 1.3 or better. So the question is: should the links in the tutorial focus on being completely transparent (ie: show everything) or should they focus just on illustrating the new params we're introducing in that section? and if the later, what's the best way to make it clear that's what we're doing? : As you point out, the wt=json parameter was explicitly presented : earlier, so it seems fair game for not calling it out explicitly. But it's presented more as an asside that in that one link we're using JSON ... for the entire Sorting section that follows we don't use it again, so it's kind of confusing when the results start popuing up in json form in the highlighting section. (if we had some verbage when we introduce wt=json about the remainder of the links using that format for readability, and then we add it to all of the href's in the Sorting section itwould be a lot less suprising. : JSON prevents highlighter markup from being escaped... didn't want : anyone seeing lt;emgt; : The other benefit is vertical size - the XML format often consumed Like i said: i'm totally fine with using the JSON format in the tutorial, i just want to make it more transparent. -Hoss
Re: svn commit: r829663 - in /lucene/solr/trunk: site/tutorial.html site/tutorial.pdf src/site/src/documentation/content/xdocs/tutorial.xml
While some of this could hypothetically be confusing, I don't think it will be in reality. Surprising, yes, but I don't think in a bad way. I'm against cluttering the examples with all of the parameters... but prepending ... to show that some parameters have been omitted seems OK. I'll do it now. -Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 11:58 AM, Chris Hostetter hossman_luc...@fucit.org wrote: : These are realy URL fragments... none of the other examples show the : indent=on or the rest of the URL either, and when we get down to indent=on doesn't really affect the structure of the response docs (especially since people following the tutorial are likely to be using a browser that pretty prints the XML) ... if you set indent aside, all of the demo links in the previous versions of the tutorial were either... 1) full URLs (starting with http://...) 2) SolrQuerySyntax (w/o any url escaping or metacharacters) when the text arround them made it clear they were query sytnax examples not URL fragments 3) full /select URL query parts (ie: everything after the ?) ...the new sections you've added (highlighting faceting) *look* like they are type#3, expcet that they leave out params that change the functionality. If the link text left out *all* params except the ones being showcased and contained elipses or soemthing to indicate that they were partial... THIS: ...hl=truehl.fl=name,features INSTEAD OF: q=video cardfl=name,idhl=truehl.fl=name,features ...then it would probably be less confusing when other params besides the ones in the link text were acctually used in the link href (and would draw attention to the fact that we are building off of other params already seen) : faceting, the fl is also hidden. Showing all of the parameters i missed that you added that fl there as well (the json formating made it less obvious when looking at the result page) but it's just another example of my point. Ultimately my concern is just that we try to be consistent with our exmaple URLs, and your point about indent illustrates that we weren't really that good about it before, but let's try to be at least as good as 1.3 or better. So the question is: should the links in the tutorial focus on being completely transparent (ie: show everything) or should they focus just on illustrating the new params we're introducing in that section? and if the later, what's the best way to make it clear that's what we're doing? : As you point out, the wt=json parameter was explicitly presented : earlier, so it seems fair game for not calling it out explicitly. But it's presented more as an asside that in that one link we're using JSON ... for the entire Sorting section that follows we don't use it again, so it's kind of confusing when the results start popuing up in json form in the highlighting section. (if we had some verbage when we introduce wt=json about the remainder of the links using that format for readability, and then we add it to all of the href's in the Sorting section itwould be a lot less suprising. : JSON prevents highlighter markup from being escaped... didn't want : anyone seeing lt;emgt; : The other benefit is vertical size - the XML format often consumed Like i said: i'm totally fine with using the JSON format in the tutorial, i just want to make it more transparent. -Hoss
Re: Another RC
So, just to clarify, here's the plan as I understand it: 1. Put up a 1.4.0 RC today w/ 2.9.1-RC2 2. Commence vote on 1.4.0 3. Once 2.9.1 is finalized, replace in Solr and generate final artifacts 4. Release Is that correct? This basically works on the assumption that the only thing that has changed between 2.9.1-RC2 and 2.9.1 final is the name of the jars. If that is the case, I'm fine w/ this process. -Grant On Oct 19, 2009, at 5:57 PM, Yonik Seeley wrote: OK, so let's do the following: as soon as the Lucene 2.9.1 official RC is put up (the one that will be voted on), I'll update Solr and we can do our vote at the same time, saving 3 or 4 days... this release has really been held up long enough :-) We can re-evaluate what to do if for some reason the Lucene vote doesn't pass (i.e., we won't blindly release Solr if the lucene vote fails). Hopefully everyone has looked at the latest Solr distributions for any potential showstoppers that would cause them to vote -1 during the official vote. -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood wun...@wunderwood.org wrote: Please wait for an official release of Lucene. It makes thing SO much easier when you need to dig into the Lucene code. It is well worth a week delay. wunder On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote: On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll gsing...@apache.org wrote: Are we ready for a release? +1 I don't think we need to wait for Lucene 2.9.1 - we have all the fixes in our version, and there's little point in pushing things off yet another week. Seems like the next RC should be a *real* one (i.e. no RC label in the version, immediately call a VOTE). -Yonik http://www.lucidimagination.com I got busy at work and haven't been able to address things as much, but it seems like things are progressing. Shall I generate another RC or are we waiting for Lucene 2.9.1? If we go w/ the 2.9.1-dev, then we just need to restore the Maven stuff for them. Hopefully, that stuff was just commented out and not completely removed so as to make it a little easier to restore. -Grant
Re: Another RC
On Mon, Oct 26, 2009 at 4:00 PM, Grant Ingersoll gsing...@apache.org wrote: So, just to clarify, here's the plan as I understand it: 1. Put up a 1.4.0 RC today w/ 2.9.1-RC2 Yes, ASAP please :-) 2. Commence vote on 1.4.0 3. Once 2.9.1 is finalized, replace in Solr and generate final artifacts If the lucene vote succeeds, we have the final artifacts already, and we won't change anything. What you put up today will most likely be the *exact* bits/files we release. So updates to CHANGES/README should be made and a branch should be created, and the Solr RC built from that. -Yonik http://www.lucidimagination.com
Re: Another RC
On Oct 26, 2009, at 4:05 PM, Yonik Seeley wrote: On Mon, Oct 26, 2009 at 4:00 PM, Grant Ingersoll gsing...@apache.org wrote: So, just to clarify, here's the plan as I understand it: 1. Put up a 1.4.0 RC today w/ 2.9.1-RC2 Yes, ASAP please :-) 2. Commence vote on 1.4.0 3. Once 2.9.1 is finalized, replace in Solr and generate final artifacts If the lucene vote succeeds, we have the final artifacts already, and we won't change anything. What you put up today will most likely be the *exact* bits/files we release. So updates to CHANGES/README should be made and a branch should be created, and the Solr RC built from that. Yep, I was originally thinking the Lucene bits were named something other than what the final bits would be named, but they are not. They are, in fact, the final bits.
How To Release, specversion, version, etc.
From http://wiki.apache.org/solr/HowToRelease:
Check out the branch with: svn co https://svn.apache.org/repos/asf/lucene/solr/branches/branch-X.Y
\
Note: at the moment releases need to be done on a unix box or in a
cygwin environment with unix linefeeds, because fixcrlf is only done
on the sources in the zip artifact
Update the version numbers in common-build.xml:
specversion should be set to X.Y.M.${dateversion}, where X.Y.M is the
release being made.
version should be set to X.Y.N-dev, where N is one greater than the
release being made.
maven_version should be the same as version for release but set to X.Y-
SNAPSHOT for non-release.
Compile the code and run unit tests.
ant -Dversion=X.Y.M -Dspecversion=X.Y.M clean test
Regenerate the site docs per Website_Update_HOWTO so the
documentation included with this release will reflect the correct
version number (at the moment, this is specific to the tutorial)
Commit the build.xml and documentation changes from the previous few
steps.
Build the release.
ant -Dversion=X.Y.M -Dspecversion=X.Y.M package
Does the second step (step 7 on the wiki) occur on the branch that we
just checked out? I know in the end that I'm building w/ specversion
and version set to 1.4.0 for the release, but that update of common-
build.xml seems a bit out of place. Seems like it should read that on
the branch you set it to be X.Y.M for all three versions and on trunk
you tick the appropriate things, right? Then, the later ant commands,
when run on the branch, would not require setting -Dversion or -
Dspecversion at all, right?
This is how I am planning on doing it, but I want to update the docs,
too.
-Grant
Re: Another RC
On Oct 26, 2009, at 4:00 PM, Grant Ingersoll wrote: So, just to clarify, here's the plan as I understand it: 1. Put up a 1.4.0 RC today w/ 2.9.1-RC2 2. Commence vote on 1.4.0 3. Once 2.9.1 is finalized, replace in Solr and generate final artifacts We also must make sure the maven pom.xml points to the right place. (currently it still points to 2.9... not the solr specific ones) 4. Release Is that correct? This basically works on the assumption that the only thing that has changed between 2.9.1-RC2 and 2.9.1 final is the name of the jars. If that is the case, I'm fine w/ this process. sounds good. Thanks Grant! -Grant On Oct 19, 2009, at 5:57 PM, Yonik Seeley wrote: OK, so let's do the following: as soon as the Lucene 2.9.1 official RC is put up (the one that will be voted on), I'll update Solr and we can do our vote at the same time, saving 3 or 4 days... this release has really been held up long enough :-) We can re-evaluate what to do if for some reason the Lucene vote doesn't pass (i.e., we won't blindly release Solr if the lucene vote fails). Hopefully everyone has looked at the latest Solr distributions for any potential showstoppers that would cause them to vote -1 during the official vote. -Yonik http://www.lucidimagination.com On Mon, Oct 19, 2009 at 1:35 PM, Walter Underwood wun...@wunderwood.org wrote: Please wait for an official release of Lucene. It makes thing SO much easier when you need to dig into the Lucene code. It is well worth a week delay. wunder On Oct 19, 2009, at 10:27 AM, Yonik Seeley wrote: On Mon, Oct 19, 2009 at 10:59 AM, Grant Ingersoll gsing...@apache.org wrote: Are we ready for a release? +1 I don't think we need to wait for Lucene 2.9.1 - we have all the fixes in our version, and there's little point in pushing things off yet another week. Seems like the next RC should be a *real* one (i.e. no RC label in the version, immediately call a VOTE). -Yonik http://www.lucidimagination.com I got busy at work and haven't been able to address things as much, but it seems like things are progressing. Shall I generate another RC or are we waiting for Lucene 2.9.1? If we go w/ the 2.9.1-dev, then we just need to restore the Maven stuff for them. Hopefully, that stuff was just commented out and not completely removed so as to make it a little easier to restore. -Grant
Re: How To Release, specversion, version, etc.
On Mon, Oct 26, 2009 at 4:34 PM, Grant Ingersoll gsing...@apache.org wrote: Does the second step (step 7 on the wiki) occur on the branch that we just checked out? I know in the end that I'm building w/ specversion and version set to 1.4.0 for the release, but that update of common-build.xml seems a bit out of place. I have an easier time looking at how you want things ending up, and working backward. If someone checks out the branch or the tag for 1.4.0 and builds it themselves, we want them to get 1.4.1-dev as a version number. So... the docs (at least that little part) look fine to me. -Yonik http://www.lucidimagination.com
Re: How To Release, specversion, version, etc.
Hmm, OK. I will need to update the branch build again, then. I wasn't thinking about it for my specific release and not about going forward. On Oct 26, 2009, at 5:14 PM, Yonik Seeley wrote: On Mon, Oct 26, 2009 at 4:34 PM, Grant Ingersoll gsing...@apache.org wrote: Does the second step (step 7 on the wiki) occur on the branch that we just checked out? I know in the end that I'm building w/ specversion and version set to 1.4.0 for the release, but that update of common-build.xml seems a bit out of place. I have an easier time looking at how you want things ending up, and working backward. If someone checks out the branch or the tag for 1.4.0 and builds it themselves, we want them to get 1.4.1-dev as a version number. So... the docs (at least that little part) look fine to me. -Yonik http://www.lucidimagination.com
[VOTE] Release Solr 1.4.0
Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: svn commit: r829995 - in /lucene/java/trunk/contrib/highlighter/src/test: ./ org/apache/lucene/search/highlight/HighlighterTest.java
Yup - good point. Solr 1.4 vote just started though - doubt anyone is
willing to start over for that - if something comes up, it should prob
just be removed though.
Uwe Schindler wrote:
By the way, as Solr updated to the latest 2.9.1 artifacts: the
SolrQueryWrapper fix for highlighter is now obsolete again?
Uwe
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Monday, October 26, 2009 11:19 PM
To: java-...@lucene.apache.org
Subject: RE: svn commit: r829995 - in
/lucene/java/trunk/contrib/highlighter/src/test: ./
org/apache/lucene/search/highlight/HighlighterTest.java
Done. I thought I added it to the fixing issue's changes entry.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Mark Miller [mailto:markrmil...@gmail.com]
Sent: Monday, October 26, 2009 11:11 PM
To: java-...@lucene.apache.org
Subject: Re: svn commit: r829995 - in
/lucene/java/trunk/contrib/highlighter/src/test: ./
org/apache/lucene/search/highlight/HighlighterTest.java
We need a changes entry too right?
uschind...@apache.org wrote:
Author: uschindler
Date: Mon Oct 26 22:06:40 2009
New Revision: 829995
URL: http://svn.apache.org/viewvc?rev=829995view=rev
Log:
LUCENE-1929: Merge NumericRangeQuery tests for highlighter from 2.9
branch. The bug was already fixed by a different impl in trunk, but the
test was missing.
Modified:
lucene/java/trunk/contrib/highlighter/src/test/ (props changed)
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/search/hi
ghlight/HighlighterTest.java
Propchange: lucene/java/trunk/contrib/highlighter/src/test/
--
--
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Mon Oct 26 22:06:40 2009
@@ -0,0 +1,3 @@
+/lucene/java/branches/lucene_2_4/contrib/highlighter/src/test:748824
+/lucene/java/branches/lucene_2_9/contrib/highlighter/src/test:817269-
818600,825998,826775,829134,829816,829881
+/lucene/java/branches/lucene_2_9_back_compat_tests/contrib/highlighter/sr
c/test:818601-821336
Modified:
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/search/hi
ghlight/HighlighterTest.java
URL:
http://svn.apache.org/viewvc/lucene/java/trunk/contrib/highlighter/src/tes
t/org/apache/lucene/search/highlight/HighlighterTest.java?rev=829995r1=82
9994r2=829995view=diff
==
---
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/search/hi
ghlight/HighlighterTest.java (original)
+++
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/search/hi
ghlight/HighlighterTest.java Mon Oct 26 22:06:40 2009
@@ -46,6 +46,7 @@
import org.apache.lucene.analysis.tokenattributes.TermAttribute;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
+import org.apache.lucene.document.NumericField;
import org.apache.lucene.document.Field.Index;
import org.apache.lucene.document.Field.Store;
import org.apache.lucene.index.IndexReader;
@@ -60,6 +61,7 @@
import org.apache.lucene.search.MultiPhraseQuery;
import org.apache.lucene.search.MultiSearcher;
import org.apache.lucene.search.MultiTermQuery;
+import org.apache.lucene.search.NumericRangeQuery;
import org.apache.lucene.search.PhraseQuery;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.TermQuery;
@@ -88,6 +90,7 @@
private IndexReader reader;
static final String FIELD_NAME = contents;
+ private static final String NUMERIC_FIELD_NAME = nfield;
private Query query;
RAMDirectory ramDir;
public IndexSearcher searcher = null;
@@ -302,6 +305,30 @@
numHighlights == 4);
}
+
+ public void testNumericRangeQuery() throws Exception {
+// doesn't currently highlight, but make sure it doesn't cause
exception either
+query = NumericRangeQuery.newIntRange(NUMERIC_FIELD_NAME, 2, 6,
true, true);
+searcher = new IndexSearcher(ramDir, true);
+hits = searcher.search(query, 100);
+int maxNumFragmentsRequired = 2;
+
+QueryScorer scorer = new QueryScorer(query, FIELD_NAME);
+Highlighter highlighter = new Highlighter(this, scorer);
+
+for (int i = 0; i hits.totalHits; i++) {
+ String text =
searcher.doc(hits.scoreDocs[i].doc).get(NUMERIC_FIELD_NAME);
+ TokenStream tokenStream = analyzer.tokenStream(FIELD_NAME, new
StringReader(text));
+
+ highlighter.setTextFragmenter(new SimpleFragmenter(40));
+
+ String result =
Re: [VOTE] Release Solr 1.4.0
Hmmm, weren't you going to update the version numbers to 1.4.1-dev like we just discussed in the other thread? That way if someone changes some of the solr source from the download and recompiles, they don't get a version number of 1.4.0 -Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll gsing...@apache.org wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: [VOTE] Release Solr 1.4.0
Also, not sure what the policy is on voting on files where the pom still needs to change.. http://people.apache.org/~gsingers/solr/1.4.0/maven/org/apache/solr/solr-core/1.4.0/solr-core-1.4.0.pom points to: dependency groupIdorg.apache.lucene/groupId artifactIdlucene-analyzers/artifactId version2.9.0/version /dependency But we really want to point to 2.9.1 I guess we can go ahead and change that even though 2.9.1 does not exist in any repository yet? ryan On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote: Hmmm, weren't you going to update the version numbers to 1.4.1-dev like we just discussed in the other thread? That way if someone changes some of the solr source from the download and recompiles, they don't get a version number of 1.4.0 -Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll gsing...@apache.org wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: [VOTE] Release Solr 1.4.0
I can do it again. The generation process is pretty easy now. On Oct 26, 2009, at 6:42 PM, Ryan McKinley wrote: Also, not sure what the policy is on voting on files where the pom still needs to change.. http://people.apache.org/~gsingers/solr/1.4.0/maven/org/apache/solr/solr-core/1.4.0/solr-core-1.4.0.pom points to: dependency groupIdorg.apache.lucene/groupId artifactIdlucene-analyzers/artifactId version2.9.0/version /dependency But we really want to point to 2.9.1 I guess we can go ahead and change that even though 2.9.1 does not exist in any repository yet? ryan On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote: Hmmm, weren't you going to update the version numbers to 1.4.1-dev like we just discussed in the other thread? That way if someone changes some of the solr source from the download and recompiles, they don't get a version number of 1.4.0 -Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll gsing...@apache.org wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: [VOTE] Release Solr 1.4.0
Yes. I need to update the POMs too, so scratch this vote for a little bit. On Oct 26, 2009, at 6:35 PM, Yonik Seeley wrote: Hmmm, weren't you going to update the version numbers to 1.4.1-dev like we just discussed in the other thread? That way if someone changes some of the solr source from the download and recompiles, they don't get a version number of 1.4.0 -Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 6:15 PM, Grant Ingersoll gsing...@apache.org wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: svn commit: r829995 - in /lucene/java/trunk/contrib/highlighter/src/test: ./ org/apache/lucene/search/highlight/HighlighterTest.java
If you want to update this, go for it. I am starting over. Let me
know.
On Oct 26, 2009, at 6:24 PM, Mark Miller wrote:
Yup - good point. Solr 1.4 vote just started though - doubt anyone is
willing to start over for that - if something comes up, it should prob
just be removed though.
Uwe Schindler wrote:
By the way, as Solr updated to the latest 2.9.1 artifacts: the
SolrQueryWrapper fix for highlighter is now obsolete again?
Uwe
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Monday, October 26, 2009 11:19 PM
To: java-...@lucene.apache.org
Subject: RE: svn commit: r829995 - in
/lucene/java/trunk/contrib/highlighter/src/test: ./
org/apache/lucene/search/highlight/HighlighterTest.java
Done. I thought I added it to the fixing issue's changes entry.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Mark Miller [mailto:markrmil...@gmail.com]
Sent: Monday, October 26, 2009 11:11 PM
To: java-...@lucene.apache.org
Subject: Re: svn commit: r829995 - in
/lucene/java/trunk/contrib/highlighter/src/test: ./
org/apache/lucene/search/highlight/HighlighterTest.java
We need a changes entry too right?
uschind...@apache.org wrote:
Author: uschindler
Date: Mon Oct 26 22:06:40 2009
New Revision: 829995
URL: http://svn.apache.org/viewvc?rev=829995view=rev
Log:
LUCENE-1929: Merge NumericRangeQuery tests for highlighter from
2.9
branch. The bug was already fixed by a different impl in trunk,
but the
test was missing.
Modified:
lucene/java/trunk/contrib/highlighter/src/test/ (props
changed)
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/
search/hi
ghlight/HighlighterTest.java
Propchange: lucene/java/trunk/contrib/highlighter/src/test/
--
--
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Mon Oct 26 22:06:40 2009
@@ -0,0 +1,3 @@
+/lucene/java/branches/lucene_2_4/contrib/highlighter/src/test:
748824
+/lucene/java/branches/lucene_2_9/contrib/highlighter/src/test:
817269-
818600,825998,826775,829134,829816,829881
+/lucene/java/branches/lucene_2_9_back_compat_tests/contrib/
highlighter/sr
c/test:818601-821336
Modified:
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/
search/hi
ghlight/HighlighterTest.java
URL:
http://svn.apache.org/viewvc/lucene/java/trunk/contrib/highlighter/src/tes
t/org/apache/lucene/search/highlight/HighlighterTest.java?
rev=829995r1=82
9994r2=829995view=diff
=
=
=
=
=
=
---
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/
search/hi
ghlight/HighlighterTest.java (original)
+++
lucene/java/trunk/contrib/highlighter/src/test/org/apache/lucene/
search/hi
ghlight/HighlighterTest.java Mon Oct 26 22:06:40 2009
@@ -46,6 +46,7 @@
import org.apache.lucene.analysis.tokenattributes.TermAttribute;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
+import org.apache.lucene.document.NumericField;
import org.apache.lucene.document.Field.Index;
import org.apache.lucene.document.Field.Store;
import org.apache.lucene.index.IndexReader;
@@ -60,6 +61,7 @@
import org.apache.lucene.search.MultiPhraseQuery;
import org.apache.lucene.search.MultiSearcher;
import org.apache.lucene.search.MultiTermQuery;
+import org.apache.lucene.search.NumericRangeQuery;
import org.apache.lucene.search.PhraseQuery;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.TermQuery;
@@ -88,6 +90,7 @@
private IndexReader reader;
static final String FIELD_NAME = contents;
+ private static final String NUMERIC_FIELD_NAME = nfield;
private Query query;
RAMDirectory ramDir;
public IndexSearcher searcher = null;
@@ -302,6 +305,30 @@
numHighlights == 4);
}
+
+ public void testNumericRangeQuery() throws Exception {
+// doesn't currently highlight, but make sure it doesn't
cause
exception either
+query = NumericRangeQuery.newIntRange(NUMERIC_FIELD_NAME,
2, 6,
true, true);
+searcher = new IndexSearcher(ramDir, true);
+hits = searcher.search(query, 100);
+int maxNumFragmentsRequired = 2;
+
+QueryScorer scorer = new QueryScorer(query, FIELD_NAME);
+Highlighter highlighter = new Highlighter(this, scorer);
+
+for (int i = 0; i hits.totalHits; i++) {
+ String text =
searcher.doc(hits.scoreDocs[i].doc).get(NUMERIC_FIELD_NAME);
+ TokenStream tokenStream = analyzer.tokenStream
(FIELD_NAME, new
StringReader(text));
+
+ highlighter.setTextFragmenter(new SimpleFragmenter(40));
+
+ String result = highlighter.getBestFragments(tokenStream,
text,
maxNumFragmentsRequired,
+ ...);
+ //System.out.println(\t + result);
+}
+
+
+ }
public void testSimpleQueryScorerPhraseHighlighting2() throws
Re: svn commit: r830013 - in /lucene/solr/branches/branch-1.4: common-build.xml src/maven/solr-core-pom.xml.template
On Mon, Oct 26, 2009 at 8:14 PM, Grant Ingersoll gsing...@apache.org wrote:
Not following...
I just updated the default version to 1.4.1-dev on the branch.
I really don't know what maven_version should be set to... I guess we
can leave it at 1.4.0 for now.
This gets a little tricky w/ the Maven stuff b/c we want
it to point to the value that is actually released, which will be 2.9.1 in
the pom. So, it won't work until Lucene is actually published,
unfortunately.
We're not actually releasing before Lucene though... what doesn't work?
ant package seems to work fine...
I don't know any other way around this except waiting until 2.9.1 is
official, but people don't seem interested in that.
AC is next week - that would likely end up delaying things a further 2 weeks.
Maven is not an official requirement - we can push it out separately
when it's ready.
-Yonik
http://www.lucidimagination.com
On Oct 26, 2009, at 7:55 PM, Yonik Seeley wrote:
version needs to be 2.9.1-dev.
No idea what maven_version should be set to.
-Yonik
http://www.lucidimagination.com
On Mon, Oct 26, 2009 at 7:03 PM, gsing...@apache.org wrote:
Author: gsingers
Date: Mon Oct 26 23:03:37 2009
New Revision: 830013
URL: http://svn.apache.org/viewvc?rev=830013view=rev
Log:
specversion, Lucene maven version
Modified:
lucene/solr/branches/branch-1.4/common-build.xml
lucene/solr/branches/branch-1.4/src/maven/solr-core-pom.xml.template
Modified: lucene/solr/branches/branch-1.4/common-build.xml
URL:
http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.4/common-build.xml?rev=830013r1=830012r2=830013view=diff
==
--- lucene/solr/branches/branch-1.4/common-build.xml (original)
+++ lucene/solr/branches/branch-1.4/common-build.xml Mon Oct 26 23:03:37
2009
@@ -72,7 +72,7 @@
By default, this should be set to X.Y.M.${dateversion}
where X.Y.M is the last version released (on this branch).
--
- property name=specversion value=1.4.0 /
+ property name=specversion value=1.4.0.${dateversion} /
!-- Type of checksum to compute for distribution files --
Modified:
lucene/solr/branches/branch-1.4/src/maven/solr-core-pom.xml.template
URL:
http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.4/src/maven/solr-core-pom.xml.template?rev=830013r1=830012r2=830013view=diff
==
--- lucene/solr/branches/branch-1.4/src/maven/solr-core-pom.xml.template
(original)
+++ lucene/solr/branches/branch-1.4/src/maven/solr-core-pom.xml.template
Mon Oct 26 23:03:37 2009
@@ -49,37 +49,37 @@
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-analyzers/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-highlighter/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-queries/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-snowball/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-memory/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-misc/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
dependency
groupIdorg.apache.lucene/groupId
artifactIdlucene-spellchecker/artifactId
- version2.9.0/version
+ version2.9.1/version
/dependency
!-- Apache Commons --
Re: svn commit: r830013 - in /lucene/solr/branches/branch-1.4: common-build.xml src/maven/solr-core-pom.xml.template
On Oct 26, 2009, at 8:40 PM, Yonik Seeley wrote: On Mon, Oct 26, 2009 at 8:14 PM, Grant Ingersoll gsing...@apache.org wrote: Not following... I just updated the default version to 1.4.1-dev on the branch. I really don't know what maven_version should be set to... I guess we can leave it at 1.4.0 for now. Yeah, that is fine. I still don't get your 2.9.1-dev comment. Was that in relation to the Maven stuff or the common-build.xml stuff? FWIW, I think we are fine with the Maven stuff. This gets a little tricky w/ the Maven stuff b/c we want it to point to the value that is actually released, which will be 2.9.1 in the pom. So, it won't work until Lucene is actually published, unfortunately. We're not actually releasing before Lucene though... what doesn't work? ant package seems to work fine... I was referring to the Maven stuff that refers to the Lucene 2.9.1 POM. Thus, if someone were try to resolve the POMs now, it would fail, but they will pass by the time Solr is actually released, thus I am not worried, but someone might run into a problem in the meantime w/ it.
Re: svn commit: r830013 - in /lucene/solr/branches/branch-1.4: common-build.xml src/maven/solr-core-pom.xml.template
-Yonik http://www.lucidimagination.com On Mon, Oct 26, 2009 at 8:46 PM, Grant Ingersoll gsing...@apache.org wrote: On Oct 26, 2009, at 8:40 PM, Yonik Seeley wrote: On Mon, Oct 26, 2009 at 8:14 PM, Grant Ingersoll gsing...@apache.org wrote: Not following... I just updated the default version to 1.4.1-dev on the branch. I really don't know what maven_version should be set to... I guess we can leave it at 1.4.0 for now. Yeah, that is fine. I still don't get your 2.9.1-dev comment. Was that in relation to the Maven stuff or the common-build.xml stuff? Sorry, I meant 1.4.1-dev... mixing up with the lucene release ;-) Index: common-build.xml === --- common-build.xml(revision 830034) +++ common-build.xml(working copy) @@ -62,7 +62,7 @@ By default, this should be set to X.Y.N-dev where X.Y.N is 1 greater then the last version released (on this branch). -- - property name=version value=1.4.0 / + property name=version value=1.4.1-dev / !-- Solr Specification Version -- !-- FWIW, I think we are fine with the Maven stuff. cool. -Yonik http://www.lucidimagination.com
Re: [VOTE] Release Solr 1.4.0
OK, take two is up in the same place. Please vote. On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
Re: [VOTE] Release Solr 1.4.0
On Mon, Oct 26, 2009 at 9:58 PM, Grant Ingersoll gsing...@apache.org wrote: OK, take two is up in the same place. Please vote. I'm seeing emptiness at http://people.apache.org/~gsingers/solr/1.4.0/ -Yonik http://www.lucidimagination.com On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote: Tis the season for releases... Please vote on releasing the Solr 1.4.0 artifacts located at http://people.apache.org/~gsingers/solr/1.4.0/ (note, solr.tar and solr-maven.tar are not artifacts to be released) CHANGES are spelled out at https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt Thanks, Grant
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770358#action_12770358 ] Lance Norskog commented on SOLR-236: This looks like a really nice rework! This JIRA has been a marathon (2.5 years!), but maybe the last miles are here. Since this JIRA has so many comments, it is hard to navigate. Maybe it is a good time to close it and start a new active JIRA for the field collapsing project. 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.3 Reporter: Emmanuel Keller Fix For: 1.5 Attachments: collapsing-patch-to-1.3.0-dieter.patch, collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-3.patch, field-collapse-4-with-solrj.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-solr-236-2.patch, field-collapse-solr-236.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch, SOLR-236_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=48amid=299 The implementation add 3 new query parameters (SolrParams): 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 Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
