I'm experimenting with field collapsing in solrcloud 6.2.1 and have this
set of request parameters against a collection:
/default?indent=on&q=*:*&wt=json&fq={!collapse+field=groupid}
My default handler is just defaults:
explicit
The first query runs about
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
SolrPluginUtils.parseQueryString
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 si
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 solr/
I'm playing with the new code checked in under SOLR-572 (compliments
to everyone who worked on that!) and am having a couple of problems.
I'm running on Windows under Tomcat 5.5.25.
1. Just in comparison with the old SpellCheckerRequestHandler
methodology, when I specified in solrconfig.xml
spel
> : 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 conside
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 l
Hi,
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). The exception is this:
HTTP Status 500 - null java.lang.NullPointerExce
> 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
gene
> 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
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 ski
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
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 and
13 matches
Mail list logo
