I think this is just a broken test case. If this test is ran with:
-Dtests.seed=-289aae8d40093437:-2c1c9ffc76ccb3bd:71f64018e9abbebb
-Dtests.multiplier=3
-Dtests.nightly=true then 1300 documents with term aaa are indexed.
During searching the maximum number of documents to retrieve is hard coded
Thanks for noticing this! I should have checked the tests better
before I committed this! I also get random failures here running the
test with -Dtests.iter:
ant test -Dtestcase=TestSolrEntityProcessorUnit -Dtests.iter=1000
I'll also take a look at it.
Martijn
On 16 December 2011 13:51, Uwe
so put in a method
to compare things as maps. You'll see in the patch.
Erick
On Fri, Dec 16, 2011 at 9:11 AM, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
Thanks for noticing this! I should have checked the tests better
before I committed this! I also get random failures here
On Fri, Dec 16, 2011 at 10:03 AM, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
@Erick
Cool. This test confuses me a bit with the String[][][] that
represents a document. I'm rewriting that to use SolrTestCaseJ4.Doc
class, which I think will make the test more readable.
On 16
think the other was going to check
in the code and drop it on the floor. And since you had additional
improvements you wanted to make
Erick
On Fri, Dec 16, 2011 at 10:40 AM, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
Sure no problem.
I'll add the changes to SOLR-2975
On 2 December 2011 11:46, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
Hi Morten,
As far as I understand, I need to create a subclass of
AbstractSecondPassGroupingCollector, and for each group maintain some sort
of structure to hold on to my values.
This class is meant
Hi Morten,
As far as I understand, I need to create a subclass of
AbstractSecondPassGroupingCollector, and for each group maintain some sort
of structure to hold on to my values.
This class is meant for collecting top N documents inside a group. The
reason it is abstract is because it can get
Hi Morten,
I missed your question on the user mailing list. Here is my answer:
With the StatsComponent this isn't possible at the moment. The
StatsComponent will give you the min / max of field for the whole
query result.
If you want the min / max value per group you'll need to do some
coding.
Looks fine!
Martijn
On 30 November 2011 15:25, Morten Lied Johansen morte...@ifi.uio.no wrote:
On 30. nov. 2011 14:58, Martijn v Groningen wrote:
With the StatsComponent this isn't possible at the moment. The
StatsComponent will give you the min / max of field for the whole
query result
If I remember correctly this was done to avoid insane FieldCache usage.
If Term based grouping implementation is used then for that field an
entry is created in the FieldCache of type DocTermsIndex. It might
then happen that for other search features like sorting and faceting a
second entry is
that there are invalid combinations. (You wouldn’t change
group.method to anything else if you were using a function to group)
Thanks,
Cody
-Original Message-
From: martijn.is.h...@gmail.com [mailto:martijn.is.h...@gmail.com] On Behalf
Of Martijn v Groningen
Sent: Tuesday, November
Hi Josh,
I think this functionality is useful. I'd create an Jira issue and
attach your code as a patch. I think that the functionality should be
added to the FileListEntityProcessor since it seems to be a more
natural place for it. Maybe we need something more generic, like a
post action if a
Hi Gabriel,
I'm not an expert FileEntityProcessor user, but I'd expect a
consistent process order. Your code seems kosher to me. You use the
last modified date as order, which seems ok to me. So create a Jira
issue and attach your patch!
Martijn
On 24 October 2011 21:49, Gabriel Cooper
, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
Hi Josh,
I think this functionality is useful. I'd create an Jira issue and
attach your code as a patch. I think that the functionality should be
added to the FileListEntityProcessor since it seems to be a more
natural place for it. Maybe we
I'm not able to reproduce this failure locally with the following command:
ant test -Dtestcase=TestDistributedGrouping
-Dtestmethod=testDistribSearch
-Dtests.seed=4f7ef1931134ac6:-6aad51ee2de9b078:1761e11b17577f5
-Dtests.multiplier=5
Someone else has an idea why this failure occurs? The test did
Thanks Uwe! On my machine I only have Java 6 installed, so I didn't notice this.
On 18 September 2011 10:54, uschind...@apache.org wrote:
Author: uschindler
Date: Sun Sep 18 08:54:01 2011
New Revision: 1172226
URL: http://svn.apache.org/viewvc?rev=1172226view=rev
Log:
Remove interface
+1 All tests passed on my machine.
The Lucene release notes do contain some old highlights like join
module. I assume this will be removed, right?
On 12 September 2011 09:03, Simon Willnauer
simon.willna...@googlemail.com wrote:
+1 Changes look fine, tests work I beasted them for a couple of
I was confused about this. I thought the join contrib was released
with 3.3 release, but it wasn't. So we should highlight it now!
On 12 September 2011 18:41, Michael McCandless
luc...@mikemccandless.com wrote:
On Mon, Sep 12, 2011 at 6:20 AM, Martijn v Groningen
martijn.v.gronin...@gmail.com
I think that a boolean or enum as return value is neater (api wise) than
throwing an expection.
On 7 September 2011 15:34, Anne Veling a...@beyondtrees.com wrote:
Yes, I saw that. I would expect that to be slower. It also would not always
work as expected if the collector would be combined in
Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Martijn v Groningen martijn.v.gronin...@gmail.com schrieb:
I think that a boolean or enum as return value is neater (api wise) than
throwing an expection.
On 7 September 2011 15:34, Anne Veling a...@beyondtrees.com wrote:
Yes
I'll investigate this test failure.
On 17 August 2011 04:31, Robert Muir rcm...@gmail.com wrote:
This test fails if NUM_ORD 2, which is the case when a
-Dtests.multiplier 1 is used.
I temporarily wired NUM_ORD to 2, and reopened/put a comment on
+1
On 10 August 2011 00:38, Andi Vajda va...@osafoundation.org wrote:
+1
Andi..
On Aug 9, 2011, at 22:40, Mark Miller markrmil...@gmail.com wrote:
+1
On Aug 8, 2011, at 4:22 AM, Simon Willnauer wrote:
We are currently working on a code grant for the Kuromoji Japanese
for productType:
BOOK and DVD?
Thanks!
Josh
On Fri, Aug 5, 2011 at 4:22 AM, Martijn v Groningen
martijn.is.h...@gmail.com wrote:
Hi Josh,
For post grouping the documents don't need to reside in the same segment.
Lucene's grouping module has a collector (TermAllGroupHeadsCollector) that
can
Hi Josh,
For post grouping the documents don't need to reside in the same segment.
Lucene's grouping module has a collector (TermAllGroupHeadsCollector) that
can
collect the most relevant document for each group (GroupHead). This
collector can produce a int[] or a FixedBitSet that can be used
All test passes on my machine last night. I look into it when I've
landed.
Op 25 jul. 2011 10:25 schreef Uwe Schindler u...@thetaphi.de het
volgende:
Hi Martijn,
Do you have an idea whats wrong with this test. It fails quite often since
your commit yesterday!
Uwe
-
Uwe Schindler
Sorry forgot to add that I'll add an entry to CHANGES
On 12 July 2011 22:59, Mark Miller markrmil...@gmail.com wrote:
+1 - a bug should get a CHANGES entry and JIRA issue generally.
On Jul 12, 2011, at 4:48 PM, Yonik Seeley wrote:
Since this is a fix to a released version, we should
@Uwe
Solr does support expunge deletes:
http://wiki.apache.org/solr/UpdateXmlMessages#Optional_attributes_for_.22commit.22
On 16 June 2011 18:05, Erick Erickson erickerick...@gmail.com wrote:
OK, after more tests I'm pretty sure that my personal machine
that I'm testing on is just
grouping faceting then maybe
the bit set based system should be a separate issue? Eg, is there a
bit set implementation today in LUCENE-3079?
On Mon, Jun 13, 2011 at 2:58 PM, Martijn v Groningen
martijn.is.h...@gmail.com wrote:
There is already an issue open for this:
LUCENE-3079
I've created SOLR-2591 for removing commitLockTimeout option.
Martijn
On 4 June 2011 13:47, Mark Miller markrmil...@gmail.com wrote:
On Jun 4, 2011, at 7:42 AM, Martijn v Groningen wrote:
the commitLockTimeout option is really not used I think we should remove
this
+1.
- Mark Miller
Welcome Jan!
On 13 June 2011 17:30, Koji Sekiguchi k...@r.email.ne.jp wrote:
Welcome!
(11/06/13 23:43), Mark Miller wrote:
I'm happy to announce that the Lucene/Solr PMC has voted in Jan Høydahl as
our newest committer.
Jan, if you don't mind, could you introduce yourself with a brief
There is already an issue open for this:
LUCENE-3079
As the issues describes, the faceting in Solr relies on the schema (and off
course the UIF).
So having the noting of a FieldType in the facet module would be very
helpful for selecting the right facet implementation.
Currently in Solr there is
Hi all,
I see that commitLockTimeout option is read from the solrconfig.xml and then
set in SolrIndexConfig.commitLockTimeout, but from there it doesn't seem to
be used by other code.
I'm not sure for what it was used in the past, but if the commitLockTimeout
option is really not used I think we
Thanks everyone for the warm welcome! I'm software developer for JTeam and
live in The Netherlands. Many might know me from the famous SOLR-236 issue.
I first used Lucene / Solr three years ago and I liked it from the start!
I've used Solr and Lucene in numerous projects and I've gained quite some
Welcome Erick!
On 2 June 2011 06:45, Doron Cohen cdor...@gmail.com wrote:
Welcome Erick!
On Wed, Jun 1, 2011 at 11:39 PM, Erick Erickson
erickerick...@gmail.comwrote:
Well, let's see. I used to work for a company that had acquired
several other products. The small group I worked in
Yes, I used his patch.
2009/12/23 Noble Paul (JIRA) j...@apache.org:
[
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794050#action_12794050
]
Noble Paul commented on SOLR-236:
Hi Marc,
I'm not sure if I follow you completely, but the example you gave is
not complete. I'm missing a few tags in your example. Lets assume the
following response that the latest patches produce.
lst name=collapse_counts
str name=fieldcat/str
lst name=results
lst name=009
Is this the way the response looks like when you use teh patch?
Thanks in advance
Martijn v Groningen wrote:
Hi Marc,
I'm not sure if I follow you completely, but the example you gave is
not complete. I'm missing a few tags in your example. Lets assume the
following response
=oncollapse.field=colcollapse.includeCollapsedDocs.fl=*collapse.type=adjacentcollapse.info.doc=truecollapse.info.count=true
I search for 'aaa' in the content field. All the documents in the result
contain that string in the field content
Martijn v Groningen wrote:
Yes it should look similar to that. What
=20indent=oncollapse.field=colcollapse.includeCollapsedDocs.fl=*collapse.type=adjacentcollapse.info.doc=truecollapse.info.count=true
I search for 'aaa' in the content field. All the documents in the result
contain that string in the field content
Martijn v Groningen wrote:
Yes it should look similar
101 - 139 of 139 matches
Mail list logo
