The additional work is done in the QueryComponent I believe. There is a
flag that tells the QueryComponent if the DocSet is needed. If that's set
to true and it's not available it will build the DocSet.
We ran into the facet refinement issue I mentioned at Alfresco and I
created this ticket: https
Thanks for the explanation, Joel. When you say the query/collapse needs to
be re-run, is this the facet component that needs to do this? The confusing
part is that the debug suggests the time is being spent in the query
component when faceting is enabled. My naive reading of your response would
It's been a little while since I looked at this section of the code. But
what I believe is going on is that the queryResultCache has kicked in which
will give you the DocList (the top N docs that match query/filters/sort)
back immediately. But faceting requires a DocSet which is a bitset of all
doc
On Thu, 2015-01-22 at 22:52 +0100, Erick Erickson wrote:
> What do you think about folding this into the Solr (or Lucene?) code
> base? Or is it to specialized?
(writing under the assumption that DVEnabler actually works as it should
for everyone and not just us)
Right now it is an explicit tool.
Toke:
What do you think about folding this into the Solr (or Lucene?) code
base? Or is it to specialized?
Not sure one way or the other, just askin'
Erick
On Thu, Jan 22, 2015 at 3:47 AM, Toke Eskildsen
wrote:
> Norgorn [lsunnyd...@mail.ru] wrote:
>> Is there any way to make 'docValues="t
Norgorn [lsunnyd...@mail.ru] wrote:
> Nice, thanks!
> If u'd like to, I'll write our results with that amazing util.
By all means, please do. Good as well as bad. Independent testing is needed to
ensure proper working tools.
- Toke Eskildsen
Nice, thanks!
If u'd like to, I'll write our results with that amazing util.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-collapsing-memory-usage-tp4181092p4181159.html
Sent from the Solr - User mailing list archive at Nabble.com.
Norgorn [lsunnyd...@mail.ru] wrote:
> Is there any way to make 'docValues="true"' without reindexing?
Depends on how brave you are :-)
We recently had the same need and made
https://github.com/netarchivesuite/dvenabler
To my knowledge that is the only existing tool for that task an as we are the
Thank you for your answer.
We've found out that the problem was in our SOLR spec (heliosearch 0.08).
There are no crushes, after changing to 4.10.3 (although, there are lot of
OOMs while handling query, it's not really strange for 1.1 bil of documents
).
Now we are going to try latest Heliosearch.
Norgorn [lsunnyd...@mail.ru] wrote:
> So, as we see, memory, used by first shard to group, wasn't released.
> Caches are already nearly zero.
It should be one or the other: Either the memory is released or there is
something in the caches. Anyway, DocValues is the way to go, so ensure that it
tu
Have a look at https://issues.apache.org/jira/browse/SOLR-5027 +
https://wiki.apache.org/solr/CollapsingQParserPlugin
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Wed, Nov 13, 2013 at 2:46 PM, David Anthony Troiano <
dtr
That's not the way grouping is done.
On a first round all shards return their 10 best group (represented as
their 10 best grouping values).
As a result it's a three round thing instead of the two round for regular
search, so observing an increasing in latency is normal but not in the
realm of what
bq: Of the 10k docs,
most have a unique near duplicate hash value, so there are about 10k unique
values for the field that I'm grouping on.
I suspect (but don't know the grouping code well) that this is the issue.
You're
getting the top N groups, right? But in the general case, you can't insure
It seems like product-offer relation is what usually represents like
product-SKU or product-UPC, model-item, eg
http://blog.mikemccandless.com/2012/01/searching-relational-content-with.html
for me that denormalized children can be indexed by the following block:
{"product_id":1,
"brand":"Convers
I don't see how join would help me
I don't really have parent/child relationship, the only common field is
product_id
For example, for different sheos of same model, img and title is different
for each model :
[
{"product_id":1, "offer_id":1,"title":"Converse all star - red - 8",
"attribute_size
Mickael,
feel free to find performance comparison between query and index time joins.
http://blog.griddynamics.com/2012/08/block-join-query-performs.html
On Mon, Feb 4, 2013 at 8:20 PM, Mickael Magniez wrote:
> The problem is that i have to have right count on my resultpage, so i have
> to
> r
On Mon, Feb 4, 2013 at 10:34 AM, Mickael Magniez
wrote:
> group.ngroups=true
This is currently very inefficient - if you can live without
retrieving the total number of groups, performance should be much
better.
-Yonik
http://lucidworks.com
27;t quite follow the last point.
-Original Message-
From: Otis Gospodnetic [mailto:otis.gospodne...@gmail.com]
Sent: Friday, January 18, 2013 9:34 AM
To: solr-user@lucene.apache.org
Subject: Re: Field Collapsing - Anything in the works for multi-valued
fields?
Hi,
Instead of the mul
ludnev [mailto:mkhlud...@griddynamics.com]
> Sent: Friday, January 18, 2013 2:32 AM
> To: solr-user
> Subject: Re: Field Collapsing - Anything in the works for multi-valued
> fields?
>
> David,
>
> What's the documents and the field? It can help to suggest workaround.
18, 2013 2:32 AM
To: solr-user
Subject: Re: Field Collapsing - Anything in the works for multi-valued
fields?
David,
What's the documents and the field? It can help to suggest workaround.
On Thu, Jan 17, 2013 at 5:51 PM, David Parks wrote:
> I want to configure Field Collapsing, but m
David,
What's the documents and the field? It can help to suggest workaround.
On Thu, Jan 17, 2013 at 5:51 PM, David Parks wrote:
> I want to configure Field Collapsing, but my target field is multi-valued
> (e.g. the field I want to group on has a variable # of entries per
> document,
> 1-N e
Why is this? And what happened to
http://lucene.472066.n3.nabble.com/Re-Field-Collapsing-disable-cache-td481783.html
?
I don't see why basic caching of request -> result shouldn't be the same?
I know I could put a layer on top, but I'd like to use a built in cache if
possi
There is no cross query cache for result grouping. The only caching
option out there is the group.cache.percent option:
http://wiki.apache.org/solr/FieldCollapsing#Request_Parameters
Martijn
On 8 December 2011 14:29, Kissue Kissue wrote:
> Hi,
>
> I was just testing field collapsing in my solr a
On 10/13/2011 5:04 PM, lee carroll wrote:
current: bool //for fq which searches only current versions
last_current_at: date time // for date range queries or group sorting
what was current for a given date
sorry if i've missed a requirement
lee c
Lee the idea of "last_current_at" is interestin
sorry missed the permission stuff:
I think thats ok if you index the acl as part of the document. That is
to say each version has its own acl. Match users against version acl
data
as a filter query and use last_current_at date as a sort
On 13 October 2011 22:04, lee carroll wrote:
> current: b
current: bool //for fq which searches only current versions
last_current_at: date time // for date range queries or group sorting
what was current for a given date
sorry if i've missed a requirement
lee c
On 13 October 2011 15:01, Mike Sokolov wrote:
> We have the identical problem in our syste
We have the identical problem in our system.
Our plan is to encode the most recent version of a document using an
explicit field/value;
ie
version=current
(or maybe current=true)
We also need to be able to allow users to search for the most current,
but only within versions they have access
I don't think this possible in only one search with what Solr
currently has to offer. I guess the only way to support this, is by
post processing your results on the client side.
So for each group you display you query what to latest version is. If
that doesn't match then you omit the result from r
I believe the underlying grouping module is now technically able to do
this, because subclasses of the abstract first/second pass grouping
collectors are free to decide what type/value the "group key" is.
But, we have to fix Solr to allow for compound keys by creating the
necessary concrete subcla
Have the same requirement. What is your workaround for this?
On Thu, May 12, 2011 at 7:40 AM, arian487 wrote:
> I'm wondering if there is a way to get the field collapsing to collapse on
> multiple things? For example, is there a way to get it to collapse on a
> field (lets say 'domain') but A
Message-
From: Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: jueves, 16 de junio de 2011 12:51
To: solr-user@lucene.apache.org
Subject: Re: Field Collapsing and Grouping in Solr 3.2
Alas, no, not yet.. grouping/field collapse has had a long history with
Solr.
There were many
Alas, no, not yet.. grouping/field collapse has had a long history
with Solr.
There were many iterations on SOLR-236, but that impl was never
committed. Instead, SOLR-1682 was committed, but committed only to
trunk (never backported to 3.x despite requests).
Then, a new grouping module was facto
Here's the root issue, and all available patches:
https://issues.apache.org/jira/browse/SOLR-236
I confess I have no clue what's what here, so
you're largely on your own. There are some
encouraging titles (note you can sort the patches
by date, which might help in figuring out which
to use)..
Bes
Ah, my mistake. Thanks alot, this would be a really cool feature :)
For now I'm resorting to like making more then one query and cross
referencing the two separate queries.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-collapsing-on-multiple-fields-and-or-ranges-tp
Ahh, that's because you opened a Solr not a Lucene issue ;)
The "modules" (incl. new grouping module) are under Lucene. That's
fine, we can leave it as a Solr issue.
Mike
http://blog.mikemccandless.com
On Wed, May 18, 2011 at 4:10 PM, arian487 wrote:
> https://issues.apache.org/jira/browse/SO
https://issues.apache.org/jira/browse/SOLR-2526
modules/grouping was not a valid component so I just put it in search.
Thanks!
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-collapsing-on-multiple-fields-and-or-ranges-tp2929793p2958408.html
Sent from the Solr - User m
Start here: https://issues.apache.org/jira/browse/LUCENE
Create an account (it's free), open an issue and set the component to
"modules/grouping", fill in the fields, and submit it :)
Then maybe make a patch and attach it! Genericizing the per-doc
grouping key is important; we have an issue open
Thanks for the reply! How exactly do I open an issue?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-collapsing-on-multiple-fields-and-or-ranges-tp2929793p2958277.html
Sent from the Solr - User mailing list archive at Nabble.com.
As far as I know this is not possible today with either Solr's 4.0
grouping impl or the new grouping module (soon to be grouping in Solr
3.x).
I'm not sure about the patch on SOLR-236 though.
But it's an interesting use case; it's a compound group key, right?
You want to group by a tuple (X, Y).
bump
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-collapsing-on-multiple-fields-and-or-ranges-tp2929793p2958029.html
Sent from the Solr - User mailing list archive at Nabble.com.
I finally got it to work. The problem was that I wasn't building
example, and was using a copied version of the webapp.
This earlier webapp did not have the classpaths set for fieldcollapse.
I built example and its working now.
Thanks to everyone who helped!
On Sun, May 15, 2011 at 9:26 PM, Erick
You can just configure another directive in solrconfig.xml
if you want.
Or, copy the relevant jars to one of the directories already specified
by a
directive in the config...
Best
Erick
On Sun, May 15, 2011 at 10:18 AM, karanveer singh
wrote:
> Since I'm using solr 3.1.0, I'm guessing that t
Since I'm using solr 3.1.0, I'm guessing that the solr.fieldCollapse
classpath hasn't been set.
How exactly should I be setting this?
On Sun, May 15, 2011 at 7:08 PM, karanveer singh
wrote:
> Can you tell me how the packet paths are set? So that I can modify
> them and let it know where to find f
Can you tell me how the packet paths are set? So that I can modify
them and let it know where to find fieldCollapse.class?
My fieldCollapse.class is in build/solr/org/apache/solr/handler/component
My /lib folder contains some .jar files and some other files, I guess
these were created at the time
Hello.
Where did you put the .class files associated to FieldCollapsing? It´s usual
to include them into a .jar contained in /lib server folder, for example.
Another option is that the packet path "solr.CollapseComponent" it´s not the
same as the applied in your patch, if it was modified.
Hi Mark,
I don't think there's anything for 1.4.1. There are SOLR-236 and SOLR-1682 (in
trunk). Neither one works for distributed search. SOLR-2066 has a patch for
field collapsing / results grouping in distributed search, but it doesn't seem
to work well.
Otis
Sematext :: http://semat
On Tue, Dec 7, 2010 at 9:07 AM, ssetem wrote:
> Thanks for the reply,
>
> How would i get the total amount of possible facets(non zero), I've searched
> around but have no luck.
Only current way would be to request them all.
Just like field collapsing, this is a number we don't (generally)
have.
Thanks for the reply,
How would i get the total amount of possible facets(non zero), I've searched
around but have no luck.
Cheers
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-Collapsing-sort-by-group-count-get-total-groups-tp2033086p2033645.html
Sent from the Solr
On Tue, Dec 7, 2010 at 7:03 AM, ssetem wrote:
> I wondered if it is possible to sort groups by the total within the group,
> and to bring back total amount groups?
That is planned, but not currently implemented.
You can use faceting to get both totals and sort by highest total though.
Total numb
Hi Mozzam,
I finally got it working
Thanks a ton guys :)
Regards
Raakhi
On Sat, Jul 10, 2010 at 10:45 AM, Moazzam Khan wrote:
> Hi Rakhi,
>
> Sorry, I didn't see this email until just now. Did you get it working?
>
>
> If not here's some things that might help.
>
>
> - Downloa
Hi Rakhi,
Sorry, I didn't see this email until just now. Did you get it working?
If not here's some things that might help.
- Download the patch first.
- Check the date on which the patch was released.
- Download the version of the trunk that existed at that date.
- Apply the patch using the p
Hi,
But these is almost no settings in my config
heres a snapshot of what i have in my solrconfig.xml
*:*
Am i goin wrong anywhere?
Regards,
Raakhi
On Wed, Jun 23, 2010 at 3:28 PM, Govind Kanshi wrote:
> fieldType:analyzer without class or tokenizer & filter list seems to p
fieldType:analyzer without class or tokenizer & filter list seems to point
to the config - you may want to correct.
On Wed, Jun 23, 2010 at 3:09 PM, Rakhi Khatwani wrote:
> Hi,
>I checked out modules & lucene from the trunk.
> Performed a build using the following commands
> ant clean
>
Hi,
I checked out modules & lucene from the trunk.
Performed a build using the following commands
ant clean
ant compile
ant example
Which compiled successfully.
I then put my existing index(using schema.xml from solr1.4.0/conf/solr/) in
the multicore folder, configured solr.xml and start
Oops this is probably i didn't checkout the modules file from the trunk.
doing that right now :)
Regards
Raakhi
On Wed, Jun 23, 2010 at 1:12 PM, Rakhi Khatwani wrote:
> Hi,
>Patching did work. but when i build the trunk, i get the following
> exception:
>
> [SolrTrunk]# ant compile
> Bu
Hi,
Patching did work. but when i build the trunk, i get the following
exception:
[SolrTrunk]# ant compile
Buildfile: /testWorkspace/SolrTrunk/build.xml
init-forrest-entities:
[mkdir] Created dir: /testWorkspace/SolrTrunk/build
[mkdir] Created dir: /testWorkspace/SolrTrunk/build/web
c
What exactly did not work? Patching, compiling or running it?
On 22 June 2010 16:06, Rakhi Khatwani wrote:
> Hi,
> I tried checking out the latest code (rev 956715) the patch did not
> work on it.
> Infact i even tried hunting for the revision mentioned earlier in this
> thread (i.e. rev 955
Hi,
I tried checking out the latest code (rev 956715) the patch did not
work on it.
Infact i even tried hunting for the revision mentioned earlier in this
thread (i.e. rev 955615) but cannot find it in the repository. (it has
revision 955569 followed by revision 955785).
Any pointers??
Regar
Oh in that case is the code stable enough to use it for production?
- Well this feature is a patch and I think that says it all.
Although bugs are fixed it is deferentially an experimental feature
and people should keep that in mind when using one of the patches.
Does it support features which
Hi,
Oh in that case is the code stable enough to use it for production?
Does it support features which solr 1.4 normally supports?
I am using facets as a workaround but then i am not able to sort on any
other field. is there any workaround to support this feature??
Regards,
Raakhi
On Fri, Ju
Hi Rakhi,
The patch is not compatible with 1.4. If you want to work with the
trunk. I'll need to get the src from
https://svn.apache.org/repos/asf/lucene/dev/trunk/
Martijn
On 18 June 2010 13:46, Rakhi Khatwani wrote:
> Hi Moazzam,
>
> Where did u get the src code from??
>
> I
Hi Moazzam,
Where did u get the src code from??
I am downloading it from
https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4
and the latest revision in this location is 955469.
so applying the latest patch(dated 17th june 2010) on it still generates
errors.
Any P
On Jun 17, 2010, at 7:44 PM, Mark Diggory wrote:
when I saw what was done with the "templating" of the Maven pom
work that was originally donated to solr, I just cringed at it.
Most of us Solr committers are fairly anti-Maven or ambivalent about
it at best, so it hasn't gotten much TLC, ad
Erik,
I try not to be exclusionary of others development tool choices in the
selection of my own. However, just to surely stir up a nest of hornets in true
Apache fashion... when I saw what was done with the "templating" of the Maven
pom work that was originally donated to solr, I just cringed
I knew it wasn't me! :)
I found the patch just before I read this and applied it to the trunk
and it works!
Thanks Mark and martijn for all your help!
- Moazzam
On Thu, Jun 17, 2010 at 2:16 PM, Martijn v Groningen
wrote:
> I've added a new patch to the issue, so building the trunk (rev
> 95561
I've added a new patch to the issue, so building the trunk (rev
955615) with the latest patch should not be a problem. Due to recent
changes in the Lucene trunk the patch was not compatible.
On 17 June 2010 20:20, Erik Hatcher wrote:
>
> On Jun 16, 2010, at 7:31 PM, Mark Diggory wrote:
>>
>> p.s.
On Jun 16, 2010, at 7:31 PM, Mark Diggory wrote:
p.s. I'd be glad to contribute our Maven build re-organization back
to the community to get Solr properly Mavenized so that it can be
distributed and released more often. For us the benefit of this
structure is that we will be able to overla
gt;>>>>> comments
>>>>>>>> below left me confused.
>>>>>>>>
>>>>>>>> i tried applyin the patch file on 1.4.0 release but ended up with
>>> many
>>>>>>>> compile errors.
>>>>&
;>> >> Hi,
>> >>> >> I wanted to try out field collapsing for a requirement. i went
>> >>> through
>> >>> >> the wiki and solr-236. but there are lot of patch files. and the
>> >>> comments
>> >>> >
> >>> >> compile errors.
> >>> >> i even downloaded the latest code from the repository and applied
> the
> >>> >> patch(solr-trunk-236 dtd 16th May 2010). but ended up with build
> errors.
> >>> >>
> >&
or
>> production use? I really need this feature so I don't think I have much of a
>> choice. Can you also explain the performance implications you are seeing AND
>> what configuration tweaks you've used that helped.
>>
>> Thanks!
>>
>>> From: ma
wrote:
>>> >>
>>> >>>
>>> >>> What do you mean you had to revert to Trunk 1.5. Do you mean upgrade?
>>> Which
>>> >>> version were you using before hand?
>>> >>>
>>> >>> Can you please list the exa
the exact version of 1.5 and the patch # you used.
>> I
>> >>> downloaded the latest nightly build and tried patching using the 2/1
>> patch.
>> >>> Everything went ok but I am getting 1 failing test.
>> >>>
>> >>> Would you
> downloaded the latest nightly build and tried patching using the 2/1
> patch.
> >>> Everything went ok but I am getting 1 failing test.
> >>>
> >>> Would you recommend using the latest nightly 1.5 build or 1.4 for
> >>> production use? I really
so I don't think I have much of a
>>> choice. Can you also explain the performance implications you are seeing AND
>>> what configuration tweaks you've used that helped.
>>>
>>> Thanks!
>>>
>>> > From: mark.robe...@red-gate.com
&
to Trunk (1.5) to get
>> the patch to apply.
>> >
>> > It does certainly have some performance implications, but tweaking
>> configuration can help here.
>> >
>> > Overall the benefits very much outweigh the costs for us :)
>> >
>> >
weaks you've used that helped.
>
> Thanks!
>
> > From: mark.robe...@red-gate.com
> > To: solr-user@lucene.apache.org
> > Date: Thu, 25 Mar 2010 15:21:54 +
> > Subject: RE: Field Collapsing SOLR-236
> >
> > Yeah got it working fine - but I neede
Finally I get it working. It seems that latest SOLR-236-trunk.patch
just have some bugs.
I checked out an older revision of solr trunk - rev 899572 (dtd.
2010-01-15) from http://svn.apache.org/repos/asf/lucene/solr/trunk
and applied SOLR-236.patch dtd. 2010-02-01.
And collapsing works fine. I ge
Joe, thanks for your answer. But it doesn't solve my problem. Below I
gave a longer description of my problem.
First of all, I checked out solr trunk revision 928303 with last
change dtd. 2010-03-28. Then I applied the latest patch from SOLR-236
to get field collapsing component. After that I buil
dont know if its the best solution but i have a field i facet on
called type its either 0,1, combined with collapse.facet=before i just
sum all the values of the facet field to get the total number found
if you dont have such a field u can always add a field with a single value
--joe
On Wed, May
hat helped.
Thanks!
> From: mark.robe...@red-gate.com
> To: solr-user@lucene.apache.org
> Date: Thu, 25 Mar 2010 15:21:54 +0000
> Subject: RE: Field Collapsing SOLR-236
>
> Yeah got it working fine - but I needed to revert to Trunk (1.5) to get the
> patch to apply.
>
> It
Thanks Ill give field-collapse-5 a try although I heard it has some bad memory
bugs in it.
> From: martijn.is.h...@gmail.com
> Date: Thu, 25 Mar 2010 13:29:30 +0100
> Subject: Re: Field Collapsing SOLR-236
> To: solr-user@lucene.apache.org
>
> Hi Blargy,
>
> The lates
: Dennis Gearon [mailto:gear...@sbcglobal.net]
Sent: 25 March 2010 00:49
To: solr-user@lucene.apache.org
Subject: Re: Field Collapsing SOLR-236
Boy, I hope that field collapsing works! I'm planning on using it heavily.
Dennis Gearon
Signature Warning
EARTH has a Right To
Hi Blargy,
The latest path is not compatible with 1.4, I believe that the latest
field-collapse-5.patch file is compatible with 1.4. The file should at
least compile with 1.4 trunk. I'm not sure how the performance is.
Martijn
On 25 March 2010 01:49, Dennis Gearon wrote:
> Boy, I hope that fiel
Boy, I hope that field collapsing works! I'm planning on using it heavily.
Dennis Gearon
Signature Warning
EARTH has a Right To Life,
otherwise we all die.
Read 'Hot, Flat, and Crowded'
Laugh at http://www.yert.com/film.php
--- On Wed, 3/24/10, blargy wrote:
> From: blargy
this has come up before, my suggestions would be to use the 12/24
patch with trunk revision 892336
http://www.lucidimagination.com/search/document/797549d29e1810d9/solr_1_4_field_collapsing_what_are_the_steps_for_applying_the_solr_236_patch
2010/1/19 Licinio Fernández Maurelo :
> Hi folks,
>
> i'
Here's the sorlconfig, with a few fields removed from the request (which
shouldn't make any difference)
http://www.intelcompute.com/solrconfig.xml
perhaps an old solrconfig to start with? tho it came no later than a 1.3
standard config file.
On Wed 23/12/09 21:33 , Martijn v Groningen wr
How have you configured field collapsing?
I have field collapsing configured without caching like this:
and with caching like this:
In both situations I don't get NPE. Also the line (in the patch) where
the exceptions occurs seems unlikely for a NPE.
if (fieldCollapseCache != null) {
Still seeing the same error when trying to comment out the fieldCollapsing
block, or even just the fieldCollapseCache block inside it to disable the cache.
fresh trunk and latest patch.
message null java.lang.NullPointerException at
org.apache.solr.search.fieldcollapse.AbstractDocumentCollap
Thanks, that latest update to the patch works fine now.
On Wed 23/12/09 13:13 , Martijn v Groningen wrote:
> Latest SOLR-236.patch is for the trunk, if have updated the latest
> patch so it should patch now without conflicts. If I remember
> correctly the latest field-collapse-5.patch should
Latest SOLR-236.patch is for the trunk, if have updated the latest
patch so it should patch now without conflicts. If I remember
correctly the latest field-collapse-5.patch should work for 1.4, but
it doesn't for the trunk.
2009/12/23 :
>
> Sorry, that was when trying to patch the 1.4 branch
>
>
Sorry, that was when trying to patch the 1.4 branch
attempting to patch the trunk gives...
patching file src/test/test-files/fieldcollapse/testResponse.xml
patching file src/test/org/apache/solr/BaseDistributedSearchTestCase.java
Hunk #2 FAILED at 502.
1 out of 2 hunks FAILED -- saving rejects t
I'm currently trying to patch aginst trunk, using SOLR-236.patch from
18/12/2009 but getting the following error...
[...@intelcompute solr]$ patch -p0 < SOLR-236.patch
patching file src/test/test-files/solr/conf/solrconfig-fieldcollapse.xml
patching file src/test/test-files/solr/conf/schema-fi
To avoid this possible bug, you could change the cache to only have a
few entries.
On Tue, Dec 22, 2009 at 6:34 AM, Martijn v Groningen
wrote:
> In the latest patch some changes where made on the configuration side,
> but if you add the CollapseComponent to the conf no field collapse
> cache shou
In the latest patch some changes where made on the configuration side,
but if you add the CollapseComponent to the conf no field collapse
cache should be enabled. If not let me know.
Martijn
2009/12/22 :
>
>
>
>
>
> On Tue 22/12/09 12:28 , Martijn v Groningen wrote:
>
>> Hi Rob,
>> What patch a
On Tue 22/12/09 12:28 , Martijn v Groningen wrote:
> Hi Rob,
> What patch are you actually using from SOLR-236?
> Martijn
> 2009/12/22 :
> > I've tried both, the whole fieldCollapsing tag, and just the
> > fieldCollapseCache tag inside it.
> >both cause error.
> >I guess I c
actually i got field-collapse-5.patch, what's the diff?
On Tue 22/12/09 12:28 , Martijn v Groningen wrote:
> Hi Rob,
> What patch are you actually using from SOLR-236?
> Martijn
> 2009/12/22 :
> > I've tried both, the whole fieldCollapsing tag, and just the
> > fieldCollapseCache tag inside
Yup, that's the one, with a copy of trunk from last week.
On Tue 22/12/09 12:28 , Martijn v Groningen wrote:
> Hi Rob,
> What patch are you actually using from SOLR-236?
> Martijn
> 2009/12/22 :
> > I've tried both, the whole fieldCollapsing tag, and just the
> > fieldCollapseCache tag insid
Hi Rob,
What patch are you actually using from SOLR-236?
Martijn
2009/12/22 :
> I've tried both, the whole fieldCollapsing tag, and just the
> fieldCollapseCache tag inside it.
> both cause error.
> I guess I can just set size, initialSize, and autowarmCount to 0 ??
> On Tue 22/12
I've tried both, the whole fieldCollapsing tag, and just the
fieldCollapseCache tag inside it.
both cause error.
I guess I can just set size, initialSize, and autowarmCount to 0 ??
On Tue 22/12/09 11:17 , Toby Cole wrote:Which elements did you
comment out? It could be the case that
1 - 100 of 142 matches
Mail list logo
