I'm experimenting with field collapsing in solrcloud 6.2.1 and have this
set of request parameters against a collection:
/default?indent=on=*:*=json={!collapse+field=groupid}
My default handler is just defaults:
explicit
The first query runs about 600ms,
Hello,
I'm working on an upgrade from solr 1.4.1 to 4.4. One of my field
analyzers uses StopWordFilter, which as of 4.4 is forbidden to set
enablePositionIncrements to false. As a consequence, some hand-constructed
phrase queries (basically generated via calls to
I finally had a chance to get back to this and got the file-based
spell checker up and going. I thought I'd close the loop on this
thread in case others downstream somehow managed to reproduce my
silliness.
I see the n-grams (n=3,4) but the text looks interspersed with spaces.
The issue was
Shalin:
The index directory location is being created inside the current working
directory. We should change that. I've opened SOLR-604 and attached a patch
which fixes this.
I updated from nightly build to incorporate your fix and it works
perfectly, now building the spell indexes in
: I'm just looking into transitioning from solr 1.2 to 1.3 (trunk). I
: have some legacy handler code (called AdvancedRequestHandler) that
: used to work with 1.2 but now throws an exception using 1.3 (latest
: nightly build).
This is an interesting use case that wasn't really considered
I'm playing around with the spell checker on 1.3 nightly build and
don't see any effect on changes to the sp.dictionary.threshold in
terms of dictionary size. A value of 0.0 seems to create a dictionary
of the same size and content as a value of 0.9. (I'd expect a very
small dictionary in the
We use two fields, one with and one without stopwords. The exact
field has a higher boost than the other. That works pretty well.
Thanks for the tip, wunder! We are doing likewise for our pf parm of
DisMax and that part works well -- exact matches are highly relevant
and stopped-matches less
sure, but what logic would you suggest be used to decide when to make them
optional? :)
Operationally, I was thinking a tokenizer could use the stop-word list
(or an optional-word list) to mark tokens as optional rather than
removing them from the token stream. DisMaxOptional would then
I've followed the stop-word discussion with some interest, but I've
yet to find a solution that completely satisfies our needs. I was
wondering if anyone could suggest some other options to try short of a
custom handler or building our own queries (DisMax does such a fine
job generally!).
We are
Hi Otis,
I skimmed your email. You are indexing book and music titles. Those tend to
be short.
Do you really benefit from removing stop words in the first place? I'd try
keeping all the stop
words and seeing if that has any negative side-effects in your context.
Thanks for your skim
Pardon the basicness of these questions, but I'm just getting started
with SOLR and have a couple of confusions regarding sorting that I
couldn't resolve based on the docs or an archive search.
1. There appears to be (at least) two ways to specify sorting, one
involving an append to the q parm
11 matches
Mail list logo
