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 the use case. Two things: 1. Regarding your confusion on docid and facets being sometimes 2: without revealing the business details, I can tell you that we split our incoming documents in parts and store them as separate documents in solr. But we use common docid for all of them in order to restore the original document when needed. However we would like to facet on them in normal solr facet meaning. 2. We have shards, because of the volume of data. As previously said, we use logical sharding. Since each shard belong to a certain period of time (non intersecting with other shards), we know in advance that a user query most likely hits only specific shards. So we didn't want other shards to search in vain and solr merger waiting for them. We implemented a router by extending solr 1.4 source code. The router operates with 15 shards currently. Let me know, if I can help with more details on our use case. Dmitry On Wed, Sep 21, 2011 at 8:56 AM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : 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 shard. > > I take thta back ... after replying to your email i noticed the "1.4" in > the subject, and it occured to me there might have been a bug in 1.4 that > was since fixed. doing a quick search i realized there *is* an open bug > that relates to your problem that i just wasn't aware of... > > https://issues.apache.org/jira/browse/SOLR-2403 > > there's some discussion in there that explains how the problem is > happening -- the crux being that becuase the mincount can't be checked > until the per-shard requests are merged, it's possible to miss some values > when doing index (aka: "lex") ordering. > > the bad news is, a general fix sounds kind of hard. the good news is, > that for mincount=1, the solution seems pretty straight forward -- we just > need someone to try working up a patch and some test cases. > > FWIW: I'd still like to here more about your usecase, because i still > think there might be a better alternative... > > : Furthermore: what you are doing is a *really* wacky use of faceting ... i > : have honestly never seen anything like it, hence my question about the > : significance of the "docid1" and "docid2" in your example field values -- > : can you elaborate on what these values mean, and how you are ultimately > : using the facet results you get back? because i am seriously curious as > : to your use case, and more then a little suspicios that there might be a > : simpler and more efficient way to solve whatever use case you have... > : > : https://people.apache.org/~hossman/#xyproblem > : XY Problem > : > : Your question appears to be an "XY Problem" ... that is: you are dealing > : with "X", you are assuming "Y" will help you, and you are asking about > "Y" > : without giving more details about the "X" so that we can understand the > : full issue. Perhaps the best solution doesn't involve "Y" at all? > : See Also: http://www.perlmonks.org/index.pl?node_id=542341 > > > -Hoss > -- Regards, Dmitry Kan
