Thanks, Erick! That sounds great. I really do have to upgrade.
Chantal
On Sun, 2012-01-01 at 16:42 +0100, Erick Erickson wrote:
Chantal:
bq: The problem with the wildcard searches is that the input is not
analyzed.
As of 3.6/4.0, this is no longer entirely true. Some analysis is
Hi Erick,
Thanks a lot for the suggestions. Tried the 3.x solr version and the search
is happening fine. Will reach out in case of any further doubts in the
latest 3.x version.
Thanks.
--
View this message in context:
Hi,
I have a few doubts regarding the segment files. I have a optimized data in
my solr core and the following are the files there
{_2ni.fdt,_2ni.fdx,_2ni.fnm,_2ni..frq,_2ni..nrm,_2ni..prx,_2ni..tii,_2ni.tis}
and two other files {segments.gen,segments_2hr}.
My understanding is that those 8 files
Hello
We are working with solr 4.0, the spellchecker used is still the classic
IndexBasedSpellChecker. Now every time I do a commit, it rebuilds the
spellchecker index, even though I clearly state a build on optimize. The
configuration in solrconfig looks like this:
I call commits testwise
Hi,
I implemented TextProfileSignature dedupe as suggested but here is something
weired which I came through while implementing -
I am testing it with two documents and trying to index them .
Please see the below content-
Content starts Here
I bought a Toyota Camry in 2007. After driven
Hi,
Can someone tell me if this is correct behavior from Solr.
I search on a dynamic field:
field_t:[* TO *]
I set highlight fields to field_t,text_t but I am not searching
specifically inside text_t field.
The highlights for text_t come back with EVERY WORD. Maybe because of
the [* TO
hi
After soft-commit with below command all cache are cleared. Is it normal?
curl http://localhost:8984/solr/update -H Content-Type: text/xml
--data-binary 'commit softCommit=true waitFlush=false
waitSearcher=false/'
--
View this message in context:
Yes, soft commit currently clears Solr's caches.
On Mon, Jan 2, 2012 at 12:01 PM, ramires uy...@beriltech.com wrote:
hi
After soft-commit with below command all cache are cleared. Is it normal?
curl http://localhost:8984/solr/update -H Content-Type: text/xml
--data-binary 'commit
Olivier, your log snippets did not make it into the mail. I think the mailing
list strips attachments.
Did you reload core or restart Jetty/Tomcat after your changes?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 2. jan.
Right - in most NRT cases (very frequent soft commits), the cache should
probably be disabled.
2012/1/2 Tomás Fernández Löbbe tomasflo...@gmail.com
Yes, soft commit currently clears Solr's caches.
On Mon, Jan 2, 2012 at 12:01 PM, ramires uy...@beriltech.com wrote:
hi
After soft-commit
On 12/29/2011 3:51 PM, Devon Baumgarten wrote:
N-Grams get me pretty great results in general, but I don't want the results
for this particular search to be fuzzy. How can I prevent the fuzzy matches
from appearing?
Ex: If I search Albatross I want Albert to be excluded completely, rather
On 1/2/2012 5:10 AM, mechravi25 wrote:
My solrconfig.xml file has the following details
ramBufferSizeMB320/ramBufferSizeMB
mergeFactor10/mergeFactor
maxBufferedDocs10/maxBufferedDocs
I am now adding only one document to the index without optimizing and i
notice that another
Hi
Looks like they strip the raw-Text for the list. Whole message here:
http://lucene.472066.n3.nabble.com/spellcheck-index-is-rebuilt-on-commit-td3626492.html
Yes, I did restart tomcat.
Thanks
Oliver
Zitat von Jan Høydahl / Cominvent [via Lucene]
ml-node+s472066n3627105...@n3.nabble.com:
hey, is it possible that during those commits nothing has changed in
the index? I mean are you committing nevertheless there are changes?
if so this could happen since the spellchecker gets a new even that
you did a commit but the index didn't really change. The spellchecker
really only checks if
Hi Darren,
This is the expected behavior. Have you tried setting the
hl.requireFieldMatch parameter to true? See:
http://wiki.apache.org/solr/HighlightingParameters#hl.requireFieldMatch
*Juan*
On Mon, Jan 2, 2012 at 10:54 AM, Darren Govoni dar...@ontrenet.com wrote:
Hi,
Can someone tell
Yeah, the only code path I can see this happening on is:
newSearcher.getIndexReader().getSequentialSubReaders().length == 1
So if you keep issuing commits on an optimized index, it will open a new
Searcher and keep rebuilding the index.
Really, this should probably *only* trigger on an
Reproduced this both on 3.X and trunk using exampledocs.
If you have an optimized index, then reindex ALL docs with a COMMIT, then there
will be only one segment, probably because all docs in the previous segment
were deleted. Adding just a few docs and COMMITting does not trigger this case.
--
On Mon, Jan 2, 2012 at 1:28 PM, Mark Miller markrmil...@gmail.com wrote:
Right - in most NRT cases (very frequent soft commits), the cache should
probably be disabled.
Did you mean autowarm should be disabled (as it already is in the
example config)?
It still normally makes sense to have the
Hi Juan,
Setting that parameter produces the same extraneous results. Here is
my query:
{!lucene q.op=OR df=text_t} kind_s:doc AND (( field_t:[* TO *] ))
Clearly, the default field (text_t) is not being searched by this query
and highlighting it would be semantically incongruent with the
Forgot to add, that the time when I DO want the highlight to appear
would be with a query that DOES match the default field.
{!lucene q.op=OR df=text_t} kind_s:doc AND (( field_t:[* TO *] )) cars
Where the term 'cars' would be matched against the df. Then I want the
highlight for it.
If
Hi,
I'm new to SOLR, but I've got it up and running, indexing data via the DIH,
and properly returning results for queries. I'm trying to setup another
core to run suggester, in order to autocomplete geographical locations. We
have a web application that needs to take a city, state / region,
Hi,
I'm reposting my StackOverflow question to this thread as I'm not getting
much of a response there. Thank you for any assistance you can provide!
http://stackoverflow.com/questions/8705600/using-solr-autocomplete-for-addresses
I'm new to SOLR, but I've got it up and running, indexing data
About bumping MaxBooleanQueries. You can certainly
bump it up, but it's a legitimate question whether the
user is well served by allowing that pattern as opposed
to requiring 2 or 3 leading characters. The assumption
behind the maxBooleanClause restriction is that
when there get to be that many
It still normally makes sense to have the caches enabled (esp filter and
document caches).
In the NRT case that statement is completely incorrect
On Mon, Jan 2, 2012 at 5:37 PM, Yonik Seeley yo...@lucidimagination.com wrote:
On Mon, Jan 2, 2012 at 1:28 PM, Mark Miller markrmil...@gmail.com
On Mon, Jan 2, 2012 at 9:58 PM, Jason Rutherglen
jason.rutherg...@gmail.com wrote:
It still normally makes sense to have the caches enabled (esp filter and
document caches).
In the NRT case that statement is completely incorrect
*shrug*
To each their own. I stand my my statement.
-Yonik
Hi Lance,
This is out of context but still asking you the question .
I implemented TextProfileSignature dedupe as suggested but here is something
weired which I came through while implementing -
I am testing it with two documents and trying to index them .
Please see the below content-
Content
I was wondering... how does the TrieField precisionStep value affect the speed
of non-range queries and sorting?
I'm assuming that int (precisionStep=0) is no slower than tint
(precisionStep=8) for these - is that correct? tint is just faster for range
queries?
Is int any faster than tint
On Tue, Jan 3, 2012 at 12:36 AM, Michael Ryan mr...@moreover.com wrote:
I was wondering... how does the TrieField precisionStep value affect the
speed of non-range queries and sorting?
I'm assuming that int (precisionStep=0) is no slower than tint
(precisionStep=8) for these - is that
28 matches
Mail list logo
