Bill,
I do not believe there is any way to tell it to use a different datasource for
the parent delta query.
If you used this approach, would it solve your problem:
http://wiki.apache.org/solr/DataImportHandlerDeltaQueryViaFullImport ?
James Dyer
Ingram Content Group
(615) 213-4311
Shamik,
Are you using a request handler other than /select, and if so, did you set
shards.qt in your request? It should be set to the name of the request
handler you are using.
See http://wiki.apache.org/solr/SpellCheckComponent?#Distributed_Search_Support
James Dyer
Ingram Content Group
I think delta imports only work on the parent entity and cached child entities
will load in full, even if you only need to look up a few rows for the delta.
Others though might have a way to get this to work.
Here's two possible workarounds.
On the child entity, specify:
entity
You probably want to write a custom Transformer. See:
http://wiki.apache.org/solr/DIHCustomTransformer
Or maybe a custom Evaluator. See:
http://wiki.apache.org/solr/DataImportHandler#Evaluators_-_Custom_formatting_in_queries_and_urls
Possibly one or more of the built-in Transformers will do
If you're using spellcheck.collate you can also set
spellcheck.maxCollationTries to validate each collation against the index
before suggesting it. This validation takes into account any fq parameters
on your query, so if your original query has fq=Product:Book, then the
collations returned
Which version of Solr are you running? (the post you replied to was about Solr
3.3, but the latest version now is 4.4.) Please provide configuration details
and the query you are running that causes the problem. Also explain exactly
what the problem is (query never returns?). Also explain
threat... do you want me to copy
it here? or could you see that? The subject is *spellcheck causing Core
Reload to hang*.
On Mon, Sep 16, 2013 at 5:50 PM, Dyer, James
james.d...@ingramcontent.comwrote:
Which version of Solr are you running? (the post you replied to was about
Solr 3.3
name=suggestionstr89566325415/str/arr/lststr
name=collation89566325415 /str/lst/lst/response
Regards,
Poornima
From: Dyer, James james.d...@ingramcontent.com
To: solr-user@lucene.apache.org solr-user@lucene.apache.org
Sent: Thursday, 25 July 2013 9:03 PM
I think the default SpellingQueryConverter has a hard time with terms that
contain numbers. Can you provide a failing case...the query you're executing
(with all the spellcheck.xxx params) and the spellcheck response (or lack
thereof). Is it producing any hits?
James Dyer
Ingram Content
Solr doesn't support any kind of short-circuting the original query and
returning the results of the corrected query or collation. You just re-issue
the query in a second request. This would be a nice feature to add though.
James Dyer
Ingram Content Group
(615) 213-4311
-Original
DirectSolrSpellChecker does not prepare any kind of dictionary. It just uses
the term dictionary from the indexed field. So what you are trying to do is
impossible.
You would think it would be possible with IndexBasedSpellChecker because it
creates a dictionary as a sidecar lucene index.
For this query:
http://localhost:8981/solr/articles/select?indent=trueq=Perfrm%20HVCrows=0
...do you get anything back in the spellcheck response? Is it correcting the
individual words and not giving collations? Or are you getting no individual
word suggestions also?
James Dyer
Ingram
Thanks
Brendan
On Tue, Jul 23, 2013 at 3:19 PM, Dyer, James
james.d...@ingramcontent.comwrote:
For this query:
http://localhost:8981/solr/articles/select?indent=trueq=Perfrm%20HVCrows=0
...do you get anything back in the spellcheck response? Is it correcting
the individual words
is this for:
str name=fieldspellcheck/str
is it even needed if I've specified how the spelling index terms should
analyzed with:
str name=queryAnalyzerFieldTypetext_spell/str
Thanks again
Brendan
On Tue, Jul 23, 2013 at 3:58 PM, Dyer, James
james.d...@ingramcontent.comwrote:
Try
or
spellcheck.q parameter and this tokenized text is the input the
spellcheckchecking instance.
Does that sound right?
Thanks
Brendan
On Tue, Jul 23, 2013 at 5:15 PM, Dyer, James
james.d...@ingramcontent.comwrote:
I don't believe you can specify more than 1 field on df (default field
DirectSorlSpellChecker does not create a dictionary. It uses the field you
specify and uses the Lucene term dictionary. It uses the some of the same code
Fuzzy Search uses to calculate distance between user input and indexed terms.
If you're wondering about the affect of configuration changes
The current implementation doesn't sort strictly on hit-counts. Rather it
gives you collations that have corrections with thenearest distance from the
original terms.
Sorting on query result score sounds like an interesting and do-able
alternative, although not supported currently. The
Instead of specifying CachedSqlEntityProcessor, you can specify
SqlEntityProcessor with cacheImpl='SortedMapBackedCache'. If you
parametertize this, to have SortedMapBackedCache for full updates but blank
for deltas I think it will cache only on the full import.
Another option is to
There are two newer parameters that work better than onlyMorePopular:
spellcheck.alternativeTermCount
- This is the # of suggestions you want for terms that exist in the index. You
can set it the same as spellcheck.count, or less if you don't want as many
suggestions for these.
My first guess is that no documents match the query provinical court.
Because you have spellcheck.maxCollationTries set to a non-zero value, it
will not return these as collations unless the correction will return hits.
You can test my theory out by removing spellcheck.maxCollationTries from
for
court and returns result.
4) Search for Provinciall Courtt = correct suggestions..
On Mon, Jun 3, 2013 at 7:55 PM, Dyer, James james.d...@ingramcontent.comwrote:
My first guess is that no documents match the query provinical court.
Because you have spellcheck.maxCollationTries set to a non
I don't want to dissuade you from trying but I believe FileListEntityProcessor
has something special coded up into it to allow for its unique usage. Not sure
if your approach isn't do-able. I would imagine that fixing FLEP to handle a
row-at-a-time or page-at-a-time in memory wouldn't be
Andy,
I opened this ticket so that someone can eventaully invistigate:
https://issues.apache.org/jira/browse/SOLR-4874
Just an instanity check, I see I had misspelled maxCollations as
maxCollation in my prior response. When you tested with this set the same as
maxCollationTries, did you
I assume here you've got a spellcheck field like this:
field name=Spelling_Dictionary type=text_general/
copyField source=field1 dest=Spelling_Dictionary /
copyField source=field2 dest=Spelling_Dictionary /
copyField source=field3 dest=Spelling_Dictionary /
copyField source=field4
a...@petdance.com wrote:
On May 29, 2013, at 9:46 AM, Dyer, James james.d...@ingramcontent.com
wrote:
Just an instanity check, I see I had misspelled maxCollations as
maxCollation in my prior response. When you tested with this set the
same as maxCollationTries, did you correct my spelling
, 2013 12:41 PM
To: solr-user@lucene.apache.org
Subject: Re: Why do FQs make my spelling suggestions so slow?
James, this is very useful information. Can you please add this to the wiki?
On Wed, May 29, 2013 at 10:36 PM, Dyer, James
james.d...@ingramcontent.comwrote:
Instead of maxCollationTries
Andy,
What are the QTimes for the 0fq,1fq,2fq,4fq 4fq cases with spellcheck
entirely turned off? Is it about (or a little more than) half the total when
maxCollationTries=1 ? Also, with the varying # of fq's, how many collation
tries does it take to get 10 collations?
Possibly, a better
Can you give instructions on how to reproduce problem?
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Rounak Jain [mailto:rouna...@gmail.com]
Sent: Thursday, May 23, 2013 7:36 AM
To: solr-user@lucene.apache.org
Subject: Bug in spellcheck.alternativeTermCount
I
as:
field name=Category1 type=string indexed=true stored=true
multiValued=true/
I am curious to what I am doing wrong. I should mention that I am using Solr
4.0.0. I know a more recent version is out – but I don’t think it should
make a difference.
Thank you again for your help.
O. O.
Dyer
column=CategoryName name=Category1 /
/entity
Similarly for other Categories i.e. Category2, Category3, etc.
I am now going to try this for a larger dataset. I hope this works.
O.O.
Dyer, James-2 wrote
There was a mistake in my last reply. Your child entities need to SELECT
First remove the where condition from the child entities, then use the
cacheKey and cacheLookup parameters to instruct DIH how to do the join.
Example:
entity
name=Cat1
cacheKey=SKU
cacheLookup=Product.SKU
query=SELECT CategoryName from CAT_TABLE where CategoryLevel=1
/
See
these basics?
O. O.
Dyer, James-2 wrote
See https://issues.apache.org/jira/browse/SOLR-2943 . You can set up 2
DIH handlers. The first would query the CAT_TABLE and save it to a
disk-backed cache, using DIHCacheWriter. You then would replace your 3
child entities in the 2nd DIH handler to use
See https://issues.apache.org/jira/browse/SOLR-2943 . You can set up 2 DIH
handlers. The first would query the CAT_TABLE and save it to a disk-backed
cache, using DIHCacheWriter. You then would replace your 3 child entities in
the 2nd DIH handler to use DIHCacheProcessor to read back the
The reason it is writing all the imput fields for that document is this
particular error message appends doc to the end, which is a subclass of
SolrInputDocument, which has a toString that shows all the fields. Not sure
if this in particular changed, but I suspect this is a symptom not a
To get a re-written query with the top suggestions, specify
spellcheck.collate=true. Begin reading from here
(http://wiki.apache.org/solr/SpellCheckComponent#spellcheck.collate) to see all
the options you have related to collate.
Solr cannot return results from a collation automatically.
by
cacheKey to lookup all records.
-Original Message-
From: Dyer, James [mailto:james.d...@ingramcontent.com]
Sent: Tuesday, May 14, 2013 4:08 PM
To: solr-user@lucene.apache.org
Subject: RE: delta-import and cache (a story in conflict)
The reason it is writing all the imput fields
?
Thanks
On Fri, May 10, 2013 at 11:34 AM, Dyer, James
james.d...@ingramcontent.comwrote:
Good point, Jason. In fact, even if you use WorkBreakSpellChecker wall
mart will not correct to walmart. The reason is the spellchecker cannot
both correct a token's spelling *and* fix the wordbreak
Despite the discussion in SOLR-3823/SOLR-3278, my experience with Solr 4.2 is
that it does indeed allow negative boosts on both bf and qf. I think the
functionality was added under the radar possibly with SOLR-4093, not sure
though. In disbelief, I did some testing and it seems to really
Nicholas,
It sounds like you might want to use WordBreakSolrSpellChecker, which gets
obscure mention in the wiki. Read through this section:
http://wiki.apache.org/solr/SpellCheckComponent#Configuration and you will see
some information.
Also, the Solr Example shows how to configure this.
, at 7:32 AM, Dyer, James james.d...@ingramcontent.com wrote:
Nicholas,
It sounds like you might want to use WordBreakSolrSpellChecker, which gets
obscure mention in the wiki. Read through this section:
http://wiki.apache.org/solr/SpellCheckComponent#Configuration and you will
see some
Try setting spellcheck.alternativeTermCount to a nonzero value. See
http://wiki.apache.org/solr/SpellCheckComponent#spellcheck.alternativeTermCount
The issue may be that by default, the spellchecker will never try to offer
suggestions for a term that exists in the dictionary. So if some other
If I remember correctly, 3.6 DIH had bugs related to CachedSqlEntityProcessor
and some were fixed in 3.6.1, 3.6.2, but some were not fixed until 4.0. You
might want to use a 3.5 DIH jar with your 3.6 Solr. Or, post your
data-config.xml and maybe someone can figure something out.
James Dyer
This sounds like https://issues.apache.org/jira/browse/SOLR-3791, which was
resolved in 3.6.2 / 4.0.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: srinalluri [mailto:nallurisr...@yahoo.com]
Sent: Monday, April 29, 2013 11:41 AM
To: solr-user@lucene.apache.org
yes, I misspoke.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: xiaoqi [mailto:belivexia...@gmail.com]
Sent: Thursday, April 25, 2013 8:37 PM
To: solr-user@lucene.apache.org
Subject: RE: Using another way instead of DIH
Thanks for help .
data-config.xml ? i
Here are some things I would try:
1. Make sure the parent entity is only returning 1 row per solr document. If
not, move the problems joins to child entities to their own queries and child
entities.
2. For the child entites, use caching. This prevents the n+1 select problem.
The changes
Gustav,
DIH should give you the same results in both scenarios. The performance
trade-offs depend on your data. In your case, it looks like there is a 1-to-1
or many-to-1 relationship between item and member, so use the SQL Join.
You'll get all of your data in one query and you'll be using
If you post your data-config.xml here, someone might be able to find something
you could change to speed things up. If the issue is parallelization, then you
could possibly partition your data somehow and then run multiple DIH request
handlers at the same time. This might be easier than
When getting collations there are two steps.
First, the spellchecker gets individual word choices for each misspelled word.
By default, these are sorted by string distance first, then document frequency
second. You can override this by specifying str
name=comparatorClassfreq/str in your
If you enable debug-level logging for class
org.apache.solr.spelling.SpellCheckCollator, you should get a log message for
every collation it tries like this:
Collation: will return zzz hits.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: SandeepM
On both queries, set spellcheck.extendedResults=true and also
spellcheck.collateExtendedResults=true, then post the full spelling response.
Also, how long does each query take on average with spellcheck turned off?
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
This doesn't make a lot of sense to me as in both cases the very first
collation it tries is the one it is returning. So you're getting a very
optimized spellcheck in both cases. But it does have to issue both queries 2
times: the first time, it tries the user's main query anding there are
I guess the first thing I'd do is to set maxCollationTries to zero. This
means it will only run your main query once and not re-run it to check the
collations. Now see if your queries have consistent qtime. One easy
explanation is that with maxCollationTries=10, it may be running your query
I do not know what it would take to have the collation tests make betetr use of
the QueryResultCache. However, outside of a test scenario, I do not know if
this would help a lot.
Hopefully you wouldn't have a lot of users issuing the exact same query with
the exact same misspelled words over
Spellcheck is broken when using both distributed and grouping. The fix is
here: https://issues.apache.org/jira/browse/SOLR-3758 . This will be part of
4.3, which likely will be released within the next few weeks. In the mean time
you can apply the patch to 4.2 or as a workaround, re-issue a
I do not believe that FileBasedSpellchecker takes frequency into account at
all. That would be a nice enhancement though.
To get what you wanted, you could index one or more documents containing the
words in your file then create a spellchecker using IndexBasedSpellChecker or
To get did-you-mean suggestions, use both spellcheck.alternativeTermCount
0 along with spellcheck.maxResultsForSuggest 0. Set this later parameter
to the max # of hits you want to trigger did-you-mean suggestions. See
If you are using dismax/edismax with mm=0 (or some other low number), you
should override this in the spellchecker. Specify
spellcheck.collateParam.mm=100%, or something high like that. Likewise if
you're using the default lucene/solr query parser with q.op=OR, then you can
specify
Make sure you also set spellcheck.onlyMorePopular=false (or leave it out as
false is the default) when using spellcheck.alternativeTermCount. You may
also need to set spellcheck.maxResultsForSuggest=0. See
http://wiki.apache.org/solr/SpellCheckComponent#spellcheck.maxResultsForSuggest
to
Use IndexBasedSpellChecker instead of DirectSolrSpellChecker if you need more
than 2 edits. You may need to set the accuracy parameter lower than the
default of .5
Keep in mind that while this might get the correct responses for your test
cases, in the wild your users might find their
I assume if your user queries delll and it breaks it into pieces like de l l
l, then you're probably using WordBreakSolrSpellChecker in addition to
DirectSolrSpellChecker, right? If so, then you can specify minBreakLength in
solrconfig.xml like this:
searchComponent name=spellcheck
You have specified spellcheck.q in your query. The whole purpose of
spellcheck.q is to bypass any query converter you've configured giving it raw
keywords instead.
But possibly a custom query converter is not your best answer?
I agree that charles charlie is an edit distance of 2, so if
You may want to run your jdbc driver in trace mode just to see if it is picking
up these different options. I know from experience that the selectMethod
parameter can sometimes be important to prevent SQLServer drivers from caching
the entire resultset in memory.
But something seems very
You do not need deltaQuery unless you're doing delta (incremental) updates.
To configure a full import, try starting with this example:
http://wiki.apache.org/solr/DataImportHandler#A_shorter_data-config
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: A. Lotfi
With MS SqlServer, try adding selectMethod=cursor to your conenction string
and set your batch size to a reasonable amount (possibly just omit it and DIH
has a default value it will use.)
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: kobe.free.wo...@gmail.com
to the class that may be responsible to this issue?
Thanks.
Alex.
-Original Message-
From: Dyer, James james.d...@ingramcontent.com
To: solr-user solr-user@lucene.apache.org
Sent: Thu, Mar 21, 2013 11:23 am
Subject: RE: strange behaviour of wordbreak spellchecker in solr cloud
The shard
is not clear.
Thanks.
Alex.
-Original Message-
From: Dyer, James james.d...@ingramcontent.com
To: solr-user solr-user@lucene.apache.org
Sent: Fri, Mar 22, 2013 2:08 pm
Subject: RE: strange behaviour of wordbreak spellchecker in solr cloud
Alex,
I added your comments to SOLR-3758
(https
lst name=grouped
lst name=site
int name=matches0/int
int name=ngroups0/int
arr name=groups/
/lst
/lst
lst name=highlighting/
lst name=spellcheck
lst name=suggestions/
/lst
/response
Thanks.
Alex.
---Original Message-
From: Dyer, James james.d...@ingramcontent.com
To: solr
Can you try including in your request the shards.qt parameter? In your case,
I think you should set it to testhandler. See
http://wiki.apache.org/solr/SpellCheckComponent?highlight=%28shards\.qt%29#Distributed_Search_Support
for a brief discussion.
James Dyer
Ingram Content Group
(615)
as
well.
- Mark
On Mar 19, 2013, at 12:18 PM, Dyer, James james.d...@ingramcontent.com
wrote:
Can you try including in your request the shards.qt parameter? In your
case, I think you should set it to testhandler. See
http://wiki.apache.org/solr/SpellCheckComponent?highlight=%28shards\.qt%29
request but it did not solve the issue.
Thanks.
Alex.
-Original Message-
From: Dyer, James james.d...@ingramcontent.com
To: solr-user solr-user@lucene.apache.org
Sent: Tue, Mar 19, 2013 10:30 am
Subject: RE: strange behaviour of wordbreak spellchecker in solr cloud
Mark,
I wasn't
There are 3 approaches I can think of:
1. You can generate a new data-config.xml for each import. With Solr 4.0 and
later, DIH re-parses your data-config.xml and picks up any changes
automatically.
2. You can parameterize nearly anything in data-config.xml, add the parameters
to your request
You can cache the subentity, then it will retrieve all the data for that entity
in 1 query.
See http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor for
more information. This section focuses on caching data from
SQLEntityProcessor. However, it is now possible to cache
Is there an easy (enough) way to do this, storing the page number as a payload
on each term?
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Michael Della Bitta [mailto:michael.della.bi...@appinions.com]
Sent: Thursday, February 28, 2013 3:33 PM
To:
I'm a little confused here because if you are searching q=jeap OR denim , then
you should be getting both documents back. Having spellcheck configured does
not affect your search results at all. Having it in your request will sometime
result in spelling suggestions, usually if one or more
I only looked at your link super fast, but this seems like a very viable
alternative to Solr's DIH. DIH does the job fairly well but we've struggled to
have developers who are willing to maintain it. The problem, I think, is that
DIH appeals to non-programmers who want to index their data
be documented in a way that persons can find this
documentation, i guess it would be better to just allow periods by changing
the implementation of the VariableResolver just a little...
00.43 now... off to bed.
Let me know what you think,
Daniel
On Wed, Feb 13, 2013 at 6:45 PM, Dyer, James
james.d
This looks like https://issues.apache.org/jira/browse/SOLR-2115 , which was
fixed for 4.0-Alpha .
Bascially, if you do not put a data-config.xml file in the defaults section
in solrconfig.xml, or if your config file has any errors, you won't be able to
use DIH unless you fix the problem and
No, you still have to fix problems with data-config.xml. Just that prior to
4.0-alpha if you started solr with a problem in the config, you had no way to
fix it and refreshing without restarting solr (or at least doing a core
reload). With 4.0, you can fix your config file and just retry.
I
The code that resolves variables in DIH was refactored extensively in 4.1.0.
So if you've got a case where it does not resolve the variables properly,
please give the details. We can open a JIRA issue and get this fixed.
James Dyer
Ingram Content Group
(615) 213-4311
-Original
The key to get this working is to set spellcheck.maxCollationTries 0. It
will generate collations even if there is only 1 term.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
Sent: Wednesday, February 13,
In your unit test, you have:
field column=\type\ name=\type\ splitBy=\\\|\ / +
And also:
runner.update(INSERT INTO test VALUES 1, 'foo,bar,baz');
So you need to decide if you want to delimit with a pipe or a comma.
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
This is a bug. Can you paste what you've said here into a new JIRA issue?
https://issues.apache.org/jira/browse/SOLR
James Dyer
Ingram Content Group
(615) 213-4311
-Original Message-
From: Jonas Birgander [mailto:jonas.birgan...@prisjakt.nu]
Sent: Wednesday, January 30, 2013 4:54 AM
I think you really need to see a thread dump when it gets stuck to know what's
going on. My original thought this was a problem with the index-based
spellchecker and wouldn't affect direct- . (for DirectSolrSpellChekcer,
spellcheck.build is a no-op as there is no separate index or dictionary
This is a bug. Thank you for reporting it. I opened this ticket:
https://issues.apache.org/jira/browse/SOLR-4361
Until there is a fix, here are two workarounds:
1. If you do not need any 4.1 DIH functionality, use the 4.0 DIH jar with your
4.1 Solr.
-or-
2. Use request parameters without
This post on stackoverflow has a good run-down on your options:
http://stackoverflow.com/questions/1555610/solr-dih-how-to-handle-deleted-documents/1557604#1557604
If you're using DIH, you can get more information from:
http://wiki.apache.org/solr/DataImportHandler
The easiest thing, if using a
I'm not sure why you have this problem. I use DIH 1.4.1 in production with
Jboss 5 (based on Tomcat) and seldom restart the JVMs and haven't experienced
anything like this. As for the warnings with ThreadLocals, I doubt these are
causing a severe memory leak: in 1.4.1, the DataImporter class
Are you trying to build the dictionary using a warming query? I think I saw
this happen once before a long time ago. I think if you are issuing a warming
query with spellcheck.build=true, then you might also want to use
spellcheck.collate=false. If this fixes it, could you open a bug report
I think your JDBC driver is complaining because it doesn't like what is being
set for the fetch size on the Statement. Fetch size is controlled by the
batchSize parameter on dataSource / .
Using batchSize=-1, I believe, is a workaround for MySql but I suspect your
driver requires it to be 0
Peter,
See http://wiki.apache.org/solr/DataImportHandler#Using_delta-import_command ,
then scroll down to where it says The deltaQuery in the above example only
detects changes in item but not in other tables... It shows you two ways to
do it.
Option 1: add a reference to the
Alexandre,
Unfortunately this is poorly documented and it takes a little trian-and-error
to figure out what is going on. I believe the order is this:
1. Get data from the EntityProcessor (in your case, MailEntityProcessor)
2. Run transformers on the data.
3. Run and post-transform operations
If the fields you're querying are of type String (1 token), then you need to
escape the whitespace with a backslash, like this:
label:ian\ paisley
If they are of type Text (multiple tokens), sometimes you need to explicitly
insert AND between each token, either with:
label:(ian AND paisley)
=q
*:* OR (constituencies:(ian paisley) OR label:(ian paisley) OR office:(ian
paisley))
/str
/lst
I do get results, but I'm not sure if putting *:* at the start will break
things down the line with other queries.
On Thu, Jan 10, 2013 at 6:36 PM, Dyer, James
james.d...@ingramcontent.comwrote
Sachin,
You might more response on this list is you can describe a little in detail
what your application needs to do. A lot of us haven't used Endeca and won't
understand exactly what you mean here.
With that said, I migrated a few apps from Endeca to Solr a few years back and
will try to
Nalini,
You could take the code from SpellCheckCollator#collate and have it issue a
test query for each word individually instead of for each collation. This
would do exactly what you want. See
are default OR. Here's the original
thread about this -
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201212.mbox/%3ccamqozyftgiwyrbvwsdf0hfz1sznkq9gnbjfdb_obnelsmvr...@mail.gmail.com%3E
Thanks,
Nalini
On Thu, Dec 27, 2012 at 2:46 PM, Dyer, James
james.d...@ingramcontent.comwrote:
https
I'm not very familiar with using scipting langauges with Java, but having seen
the DIH code for this, my guess is that all script code needs to be in the
script / section of data-config.xml. So I don't think what you want is
possible. This seems like the kind of thing that would be useful if
It looks from your stack trace that your XML document has a value for
ChemicalNameOfSubstance yet you do not have such a column defined in
schema.xml. Is this your problem?
The easiest way to get Solr to ignore extra fields that you do not wish to
index or store is to add a catch-all dynamic
the spellcheck.maxResultsForSuggest param helps with making
sure that the suggestions returned satisfy the fq params?
That's the main problem we're trying to solve, how often suggestions are
being returned is not really an issue for us at the moment.
Thanks,
Nalini
On Wed, Dec 19, 2012 at 4:35 PM, Dyer, James
james.d
, Dyer, James
james.d...@ingramcontent.com wrote:
I would say such a guarantee is implied by the javadoc to
Analyzer#getPositionIncrementGap . It says this value is an increment to
be added to the next token emitted from tokenStream.
http://lucene.apache.org/core/4_0_0-ALPHA/core/org/apache
Let me try and get a better idea of what you're after. Is it that your users
might query a combination of irrelevant terms and misspelled terms, so you want
the ability to ignore the irrelevant terms but still get suggestions for the
misspelled terms?
For instance if someone wanted
101 - 200 of 396 matches
Mail list logo
