Finally got it working - turns out you can't just add it to the lib dir as
the wiki suggests. Unfortunately the only way is adding it to solr.war.
Thanks for your help.
--
From: "William Oberman"
Sent: Friday, August 19, 2011 5:07 PM
To:
Subject
Sent from my iPhone
On Aug 21, 2011, at 5:54 AM, "Kuba Krzemien" wrote:
Finally got it working - turns out you can't just add it to the lib
dir as the wiki suggests. Unfortunately the only way is adding it to
solr.war.
Thanks for your help.
-
Wait. Sometimes I get confused because gmail will substitute
* for bolding, so in my client it looks like you're searching infix (e.g.
leading and trailing wildcards). If that's the case, then your performance
will always be poor, it has to enumerate all the terms in the field...
If it's just bold
The root problem here is "This is unacceptable for my client". The first
thing I'd suggest is that you work with your client and get them to define
what is acceptable. You'll be forever changing things (to no good purpose)
if all they can say is "that's not right".
For instance, you apparently hav
Publishing stack traces does no good unless you also tell us what version
of Solr you are using. The source-file numbers do move around between
versions
Also, what line in your code is at the root of this chain? The very first thing
I'd do is just comment out your custom code (i.e. just ahve t
At a guess, you're not getting as many rows as you think, and commit has
nothing to do with it. But that's just a guess.
So the very first thing I'd do is be sure the SQL is doing what you
think. There's
a little-known data import debugging page that might help:
blahblahblah./solr/admin/datai
Thanks for reply. I know that sometimes meeting all clients needs would be
impossible but then client recalls that competitive (commercial) product
already do that (but has other problems, like performance). And then I'm
obligated to try more tricks. :/
I'm currently using Solr 3.1 but thinking ab
On Fri, Aug 19, 2011 at 6:26 PM, Michael Ryan wrote:
> Is there a way to specify in a query that a term must match at least X times
> in a document, where X is some value greater than 1?
>
One simple way of doing this is maybe to write a wrapper for TermQuery
that only returns docs with a Term F
Would it make sense to have a "Did you mean?" type of functionality for
which you use the EdgeNGram and Metaphone filters /if/ you don't get
appropriate results for the user query?
So when user types "cannon" and the application notices that there are
no cannons for sale in the index (0 results wi
I think Sujit has hit the nail on the head. Any program you try to write
that tries to guess what the user *really* meant will require endless
tinkering and *still* won't be right. If you only knew how annoying I
find Google's attempts to "help".
So perhaps concentrating on some interaction wi
Yeah, I was searching infix. It worked very nice for autocomplete.
Made a custom QueryConverter for the Suggester so it gives proper
suggestions for shingles. Will stick with that for now.
Thanx for the feedback.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Terms-regex-pe
Thanks very much for your advice. I think I now better understand how to
make better use of solr. I have tested spellchecker and it looks like it let
me to achieve better results and hopefully we will satisfy the client.
In my solution I will change user query to use or not to use phonetic fields
Ah, in that case, comparing prefix and regex is an apples-to-oranges
comparison. I expect regex to be slower, but a fairer comparison
would be prefix to stuff* (which may be changed into a prefix
enumeration for all I know). But comparing infix to prefix doesn't tell you
much really
Best
Erick
Of course. Thats why I compared prefix to bla* and saw it was already a lot
slower.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Terms-regex-performance-issue-tp3268994p3273370.html
Sent from the Solr - User mailing list archive at Nabble.com.
I see now in Suggester Wiki; Support for infix-suggestions is planned for
FSTLookup (which would be the only structure to support these).
--
View this message in context:
http://lucene.472066.n3.nabble.com/Terms-regex-performance-issue-tp3268994p3273711.html
Sent from the Solr - User mailing lis
> One simple way of doing this is maybe to write a wrapper for TermQuery
> that only returns docs with a Term Frequency > X as far as I
> understand the question those terms don't have to be within a certain
> window right?
Correct. Terms can be anywhere in the document. I figured term frequencie
Hi all,
I am trying to use the Join feature in SOLR trunk with limited sucess. I
am able to make simple searches and get the returns of documents as
expected. A query such a follows works perfectly fine and as expected:
http://localhost:8983/solr/core0/select?q={!join%20from=matchset_id_ss%
The changes for Solrconfig.xml in solr is as follows
default
solr.IndexBasedSpellChecker
spell
./spellchecker
0.7
.0001
jarowinkler
lowerfilt
org.apache.lucene.search.spell.J
18 matches
Mail list logo