Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-10-06 Thread Dmitry Kan
Thanks Hoss, I can look into that, once done with solr router migration 1.4->3.4. Dmitry On Wed, Oct 5, 2011 at 2:13 AM, Chris Hostetter wrote: > > : OK, if SOLR-2403 being related to the bug I described, has been fixed in > : SOLR 3.4 than we are safe, since we are in the process of migration.

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-10-06 Thread Dmitry Kan
Hello, I'm now in the process of migrating solr 1.4 -> solr 3.4. It is done already, just wide scale testing remains. I'll report back if anything pops up related to the jira ticket. Otherwise I could work closer on the issue, unless it is fixed. Dmitry On Wed, Oct 5, 2011 at 4:24 AM, Yonik Seel

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-10-04 Thread Yonik Seeley
On Tue, Oct 4, 2011 at 7:13 PM, Chris Hostetter wrote: > > : OK, if SOLR-2403 being related to the bug I described, has been fixed in > : SOLR 3.4 than we are safe, since we are in the process of migration. Is it > : possible to verify this somehow? Is FacetComponent class is the one I should > :

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-10-04 Thread Chris Hostetter
: OK, if SOLR-2403 being related to the bug I described, has been fixed in : SOLR 3.4 than we are safe, since we are in the process of migration. Is it : possible to verify this somehow? Is FacetComponent class is the one I should : start checking this from? Can you give any other pointers? Accor

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-09-23 Thread Dmitry Kan
Hi, OK, if SOLR-2403 being related to the bug I described, has been fixed in SOLR 3.4 than we are safe, since we are in the process of migration. Is it possible to verify this somehow? Is FacetComponent class is the one I should start checking this from? Can you give any other pointers? OK, for t

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-09-20 Thread Chris Hostetter
: with the setup you describe, there's no why i can imagine executing a : search that results in constraints being returned that come from multiple : shards with some constraints being "missing" from the middle of hte list, : near the border of values for that field that signify a change in sha

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-09-20 Thread Chris Hostetter
: document in a shard has a field, which contains date in milliseconds which : is a result of subtraction of the original document's date from a very big : date in the future. In this way, if you issue a facet query against a shard : and use facet.method=index you get hits from the shard ordered :

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-09-14 Thread Dmitry Kan
Hi Chris, Thanks for taking this. Sorry for my confusing explanation. Since you requested a bigger picture, I'll give some more detail. In short: we don't do date facets, and sorting by date in reverse order happens naturally by design. All the data is split to shards. We use logical sharding, no

Re: solr 1.4 facet.limit behaviour in merging from several shards

2011-09-08 Thread Chris Hostetter
: When shooting a distributed query, we use facet.limit=1000. Then the merging : SOLR combines the results. We also use facet.zeros=false to ensure returning : only non-zero facet entries. : The issue that we found is that there was a gap in time in the final results : list (reverse sorted by date

solr 1.4 facet.limit behaviour in merging from several shards

2011-09-02 Thread Dmitry Kan
Hello list, Took a while to get back to following the discussions after vacation. We have recently stumbled upon an issue with distributed facet search. I would appreciate any help before checking the source code of solr 1.4 we currently use. When shooting a distributed query, we use facet.limit