olr/commit/bf9db95f218f49bac8e7971eb953a9fd9d13a2f0#diff-269ae02e56283ced3ce781cce21b3147R563
sincerely
hongtai
送信元: "Staley, Phil R - DCF"
Reply-To: "d...@lucene.apache.org"
日付: 2020年3月2日 月曜日 22:38
宛先: solr_user lucene_apache ,
"d...@lucene.apache.org"
件名: Re: strange behavior of solr query p
lucene_apache
Cc: d...@lucene.apache.org
Subject: strange behavior of solr query parser
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be
ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not
Hi,
Our team found a strange behavior of solr query parser.
In some specific cases, some conditional clauses on unindexed field will be
ignored.
for query like, q=A:1 OR B:1 OR A:2 OR B:2
if field B is not indexed(but docValues="true"), "B:1" will be lost.
but if you write
Hi David,
I see. It fixed now by adding the (). Thank you so much!
q=audit_author.name:(Burley,%20S.K.)%20AND%20entity.type:polymer
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Hi Shawn,
I see.
I added () and it works now. Thank you very much for your help!
q=audit_author.name:(Burley,%20S.K.)%20AND%20entity.type:polymer&rows=1
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
On 6/6/2019 12:46 PM, Wendy2 wrote:
Why "AND" didn't work anymore?
I use Solr 7.3.1 and edismax parser.
Could someone explain to me why the following query doesn't work any more?
What could be the cause? Thanks!
q=audit_author.name:Burley,%20S.K.%20AND%20entity.type:polymer
It worked previousl
audit_author.name:Burley,%20S.K.
translates to
audit_author.name:Burley, DEFAULT_OPERATOR DEFAULT_FIELD:S.K.
On Thu, Jun 6, 2019 at 2:46 PM Wendy2 wrote:
>
> Hi,
>
> Why "AND" didn't work anymore?
>
> I use Solr 7.3.1 and edismax parser.
> Could someone explain to me why the following query
Hi,
Why "AND" didn't work anymore?
I use Solr 7.3.1 and edismax parser.
Could someone explain to me why the following query doesn't work any more?
What could be the cause? Thanks!
q=audit_author.name:Burley,%20S.K.%20AND%20entity.type:polymer
It worked previously but now returned very lo
If anyone else is following this thread, I replied on the Jira.
On Mon, Oct 16, 2017 at 4:07 AM, alessandro.benedetti
wrote:
> This is interesting, the EFI parameter resolution should work using the
> quotes independently of the query parser.
> At that point, the query parsers (both) receive a m
This is interesting, the EFI parameter resolution should work using the
quotes independently of the query parser.
At that point, the query parsers (both) receive a multi term text.
Both of them should work the same.
At the time I saw the mail I tried to reproduce it through the LTR module
tests and
I believe I've discovered a workaround. If you use:
{
"store": "redhat_efi_feature_store",
"name": "case_description_issue_tfidf",
"class": "org.apache.solr.ltr.feature.SolrFeature",
"params": {
"q":"{!dismax qf=text_tfidf}${text}"
}
}
i
I think this has nothing to do with the LTR plugin.
The problem here should be just the way you use the local params,
to properly pass multi term local params in Solr you need to use *'* :
efi.case_description='added couple of fiber channel'
This should work.
If not only the first term will be pa
Hi all,
I'm getting some extremely strange behavior when trying to extract features
for a learning to rank model. The following query incorrectly says all
features have zero values:
http://gss-test-fusion.usersys.redhat.com:8983/solr/access/query?q=added
couple of fiber channel&rq={!
See example/films/README.txt
The “name” field is guessed incorrectly (because the first film has name=“.45”,
so indexing errors once it hits a name value that is no longer numeric. The
README provides a command to define the name field *before* indexing. If
you’ve indexed and had the name fie
Is there any error message in the log when Solr stops indexing the file at
line 2046?
Regards,
Edwin
On 2 September 2015 at 17:17, Long Yan wrote:
> Hey,
> I have created a core with
> bin\solr create -c mycore
>
> I want to index the csv sample files from solr-5.2.1
>
> If I index film.csv und
Hey,
I have created a core with
bin\solr create -c mycore
I want to index the csv sample files from solr-5.2.1
If I index film.csv under solr-5.2.1\example\films\, solr can only index this
file until the line
"2046,Wong Kar-wai,Romance Film|Fantasy|Science
Fiction|Drama,,/en/2046_2004,2004-05-2
On 8/23/2014 9:01 AM, Jack Krupansky wrote:
> It sounds as if you are trying to treat hyphen as a digit so that
> negative numbers are discrete terms. But... that conflicts with the use
> of hyphen as a word separator. Sorry, but WDF does not support both.
> Pick one or the other, you can't have bo
ve-Service-Solutions)
Sent: Thursday, August 21, 2014 2:31 PM
To: solr-user@lucene.apache.org
Subject: Strange Behavior
Hi , I have a field type text_general where query type for worddelimiter I
am using the below type: where wddftype.txt contains "- DIGIT"
When I do a query I am n
Hi , I have a field type text_general where query type for worddelimiter I am
using the below type: where wddftype.txt contains "- DIGIT"
When I do a query I am not getting the right results. E.g. Name:"Wi-Fi" Gets
results but Name:"Wi-Fi Devices Make" not getting any results
but if I change i
> > > log level in Solr to get more information logged
> > >
> > > > -Original Message-
> > > > From: S.L [mailto:simpleliving...@gmail.com]
> > > > Sent: June-06-14 2:33 PM
> > > > To: solr-user@lucene.apache.org
> >
race the process if you`re running on Unix or changed
> the
> > log level in Solr to get more information logged
> >
> > > -Original Message-
> > > From: S.L [mailto:simpleliving...@gmail.com]
> > > Sent: June-06-14 2:33 PM
> >
June-06-14 2:33 PM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Strange Behavior with Solr in Tomcat.
> >
> > Anyone folks?
> >
> >
> > On Wed, Jun 4, 2014 at 10:25 AM, S.L wrote:
> >
> > > Hi Folks,
> > >
> > &g
6-14 2:33 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Strange Behavior with Solr in Tomcat.
>
> Anyone folks?
>
>
> On Wed, Jun 4, 2014 at 10:25 AM, S.L wrote:
>
> > Hi Folks,
> >
> > I recently started using the spellchecker in my solrcon
Anyone folks?
On Wed, Jun 4, 2014 at 10:25 AM, S.L wrote:
> Hi Folks,
>
> I recently started using the spellchecker in my solrconfig.xml. I am able
> to build up an index in Solr.
>
> But,if I ever shutdown tomcat I am not able to restart it.The server never
> spits out the server startup time
Hi,
This is not a case of accidental deletion , the only way I can restart the
tomcat is by deleting the data directory for the index that was created
earlier, this started happening after I started using spellcheckers in my
solrconfig.xml. As long as the Tomcat is running its fine.
Any help from
I guess if you try to copy the index and then kill the process of tomcat
then it might help. If still the index need to be delete you would have the
back up. Next time always make back up.
On Jun 4, 2014 7:55 PM, "S.L" wrote:
> Hi Folks,
>
> I recently started using the spellchecker in my solrcon
Hi Folks,
I recently started using the spellchecker in my solrconfig.xml. I am able to
build up an index in Solr.
But,if I ever shutdown tomcat I am not able to restart it.The server never
spits out the server startup time in seconds in the logs,nor does it print any
error messages in the cata
gt; case where the query is much longer. I need to use mm=0 or mm=1.
>
> My plan was to use edismax as the pf2 and pf3 parameters should work well
> for my usecase.
>
> However when using longer queries, I get a strange behavior which can be
> seen in debugQuery.
>
> Here
query
term phrase matches exactly.
-- Jack Krupansky
From: Nils Kaiser
Sent: Friday, April 4, 2014 10:10 AM
To: solr-user@lucene.apache.org
Subject: Strange behavior of edismax and mm=0 with long queries (bug?)
Hey,
I am currently using solr to recognize songs and people from a list of user
collated comments as query. So it is a
case where the query is much longer. I need to use mm=0 or mm=1.
My plan was to use edismax as the pf2 and pf3 parameters should work well
for my usecase.
However when using longer queries, I get a strange behavior which can be
seen in debugQuery.
Here is an
aster than the other.
-- Jack Krupansky
-Original Message-
From: abhishek.netj...@gmail.com
Sent: Monday, March 31, 2014 5:48 AM
To: solr-user@lucene.apache.org ; solr-user@lucene.apache.org
Subject: Re: Strange behavior while deleting
Hi,
These settings are commented in schema. These ar
: solr-user@lucene.apache.org
Reply To: solr-user@lucene.apache.org
Subject: Re: Strange behavior while deleting
Do the two cores have identical schema and solrconfig files? Are the delete
and merge config settings the sameidentical?
Are these two cores running on the same Solr server, or two
discrepancy - just a few, dozens, 10%, 50%?
-- Jack Krupansky
-Original Message-
From: abhishek jain
Sent: Monday, March 31, 2014 3:26 AM
To: solr-user@lucene.apache.org
Subject: Strange behavior while deleting
hi friends,
I have observed a strange behavior,
I have two indexes of same ids and
hi friends,
I have observed a strange behavior,
I have two indexes of same ids and same number of docs, and i am using a
json file to delete records from both the indexes,
after deleting the ids, the resulting indexes now show different count of
docs,
Not sure why
I used curl with the same json
I'm seeing a rare behavior of the gap fragmenter on solr 3.6. Right now this is
my configuration for the gap fragmenter:
150
This is the basic configuration, just tweaked the fragsize parameter to get
shorter fragments. The thing is that for 1 particula
Hmmm, there are two things you _must_ get familiar with when diagnosing
these ..
1> admin/analysis. That'll show you exactly what the analysis chain does,
and it's
not always obvious.
2> add &debug=query to your input and look at the parsed query results. For
instance,
this "name:4nSolut
Eric,
Thank you for the explanation.
My problem was that allowing the docs with the same unique ids to be
present in the multiple shards in a "normal" situation,
makes it impossible to estimate the number of shards needed for an index
with a "really large" number of docs.
Thanks,
Val
On 05
solr-user-unsubscribe
2013/5/28 Michał Matulka
> Thanks for your responses, I must admit that after hours of trying I
> made some mistakes.
> So the most problematic phrase will now be:
> "4nSolution Inc." which cannot be found using query:
>
> name:4nSolution
>
> or even
>
> name:4nSolution
Thanks for your responses, I must admit
that after hours of trying I made some mistakes.
So the most problematic phrase will now be:
"4nSolution Inc." which cannot be found using query:
name:4nSolution
or even
name:4nSolution Inc.
Hmmm, with 4.x I get much different behavior than you're
describing, what version of Solr are you using?
Besides Alex's comments, try adding &debug=query to the url and see what comes
out from the query parser.
A quick glance at the code shows that DefaultAnalyzer is used, which doesn't do
any an
What does analyzer screen say in the Web AdminUI when you try to do that?
Also, what are the tokens stored in the field (also in Web AdminUI).
I think it is very strange to have TextField without a tokenizer chain.
Maybe you get a standard one assigned by default, but I don't know what the
standa
Hello,
I've got following problem. I have a text type in my schema and a field
"name" of that type.
That field contains a data, there is, for example, record that has
"300letters" as name.
Now field type definition:
And, of course, field definition:
yes, that's all - there are no tokenize
Hello, guys!
Well, I've done some tests and I think that there exists some kind of bug
related with distributed search. Currently I'm setting a key field that
it's impossible to be duplicated, and I have experienced the same wrong
behavior with numFound field while changing rows parameter. Has any
Hi, Erick!
That's it! I'm using a custom implementation of a SolrServer with
distributed behavior that routes queries and updates using an in-house
Round Robin method. But the thing is that I'm doing this myself because
I've noticed that duplicated documents appears using LBHttpSolrServer
implemen
Valery:
I share your puzzlement. _If_ you are letting Solr do the document
routing, and not doing any of the custom routing, then the same unique
key should be going to the same shard and replacing the previous doc
with that key.
But, if you're using custom routing, if you've been experimenting w
The uniqueKey is enforced within the same shard/index only.
On Fri, May 24, 2013 at 6:39 PM, Valery Giner wrote:
> Shawn,
>
> How is it possible for more than one document with the same unique key to
> appear in the index, even in different shards?
> Isn't it a bug by definition?
> What am I mis
Shawn,
How is it possible for more than one document with the same unique key
to appear in the index, even in different shards?
Isn't it a bug by definition?
What am I missing here?
Thanks,
Val
On 05/23/2013 09:55 AM, Shawn Heisey wrote:
On 5/23/2013 1:51 AM, Luis Cappa Banda wrote:
I've qu
Uhm... that sounds reasonable. My data model may allow duplicate keys, but
it's quite difficult. My key is a hash formed by an URL during a crawling
process, and it's posible to re-crawl an existing URL. I think that I need
to find a new way to compose an unique key to avoid this kind of bad
behavi
On 5/23/2013 1:51 AM, Luis Cappa Banda wrote:
> I've query each Solr shard server one by one and the total number of
> documents is correct. However, when I change rows parameter from 10 to 100
> the total numFound of documents change:
I've seen this problem on the list before and the cause has be
Hello, guys!
I'm running Solr 4.3.0 and I've notice an strange behavior during
distributed queries execution. Currently I have three Solr servers as
shards and I when I do the following query...
http://localhost:11080/twitter/data/select?&q=*:*&*rows=10*
&&shards=lo
t; >>> >wrote:
> >>>>
> >>>> > Hi, Sami!
> >>>> >
> >>>> > But isn´t strange that some documents were updated (atomic updates)
> >>>> > correctly and other ones not? Can´t it be a more se
hat some documents were updated (atomic updates)
>>>> > correctly and other ones not? Can´t it be a more serious problem like
>>>> some
>>>> > kind of index writer lock, or whatever?
>>>> >
>>>> > Regards,
>>>> >
; > kind of index writer lock, or whatever?
>>> >
>>> > Regards,
>>> >
>>> > - Luis Cappa.
>>> >
>>> > 2012/11/22 Sami Siren
>>> >
>>> > > I think the problem is that even though you were able to wo
the
>> atomic
>> > > update (with multivalued field) fails later down the stack. The bug
>> you
>> > > filed needs to be fixed to get the problem solved.
>> > >
>> > >
>> > > On Thu, Nov 22, 2012 at 8:19 PM
ou
> > > filed needs to be fixed to get the problem solved.
> > >
> > >
> > > On Thu, Nov 22, 2012 at 8:19 PM, Luis Cappa Banda > > >wrote:
> > >
> > > > Hello everyone.
> > > >
> > > > I´ve starting to seri
t; On Thu, Nov 22, 2012 at 8:19 PM, Luis Cappa Banda > >wrote:
> >
> > > Hello everyone.
> > >
> > > I´ve starting to seriously worry about with SolrCloud due an strange
> > > behavior that I have detected. The situation is this the fo
>wrote:
>
> > Hello everyone.
> >
> > I´ve starting to seriously worry about with SolrCloud due an strange
> > behavior that I have detected. The situation is this the following:
> >
> > *1.* SolrCloud with one shard and two Solr instanc
:19 PM, Luis Cappa Banda wrote:
> Hello everyone.
>
> I´ve starting to seriously worry about with SolrCloud due an strange
> behavior that I have detected. The situation is this the following:
>
> *1.* SolrCloud with one shard and two Solr instances.
> *2.* Indexation via SolrJ
Hello everyone.
I´ve starting to seriously worry about with SolrCloud due an strange
behavior that I have detected. The situation is this the following:
*1.* SolrCloud with one shard and two Solr instances.
*2.* Indexation via SolrJ with CloudServer and a custom
BinaryLBHttpSolrServer that uses
Thank you for verifying the issue. I've created a ticket at
https://issues.apache.org/jira/browse/SOLR-3407
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-names-w-leading-digits-cause-strange-behavior-tp3936354p3936599.html
Sent from the Solr - User mailing
get back that value as well as the behavior above.
> ...
>
> true
> 24
>
> ...
>
> Is it ok the have fields that start with digits? If so, is there a different
> way to specify them using the "fl" parameter? Thanks!
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Field-names-w-leading-digits-cause-strange-behavior-tp3936354p3936354.html
> Sent from the Solr - User mailing list archive at Nabble.com.
erent
way to specify them using the "fl" parameter? Thanks!
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-names-w-leading-digits-cause-strange-behavior-tp3936354p3936354.html
Sent from the Solr - User mailing list archive at Nabble.com.
: Would it be a good idea to have Solr throw syntax error if an empty string
: query occurs?
erick's explanation wasn't very precise ...
solr doesn't have any special handling of "empty strings", but what you
are searching for *might* be a totally valid query based on how the field
type is c
Would it be a good idea to have Solr throw syntax error if an empty string
query occurs?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Strange-behavior-with-search-on-empty-string-and-NOT-tp3818023p3823572.html
Sent from the Solr - User mailing list archive at Nabble.com.
32282")
> -name:"blah 232282"
>
> LuceneQParser
>
> 1.0
>
> 1.0
>
> 1.0
>
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
>
> 0.0
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
> 0.0
>
>
>
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Strange-behavior-with-search-on-empty-string-and-NOT-tp3818023p3818023.html
> Sent from the Solr - User mailing list archive at Nabble.com.
.0
1.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
--
View this message in context:
http://lucene.472066.n3.nabble.com/Strange-behavior-with-search-on-empty-string-and-NOT-tp3818023p3818023.html
Sent from the Solr - User mailing list archive at Nabble.com.
You might try with a less "fraught" search phrase,
"to be or not to be" is a classic query that may be all
stop words.
Otherwise, I'm clueless.
On Wed, Nov 23, 2011 at 3:15 PM, Ariel Zerbib wrote:
> I tested with the version 4.0-2011-11-04_09-29-42.
>
> Ariel
>
>
> 2011/11/17 Erick Erickson
>
I tested with the version 4.0-2011-11-04_09-29-42.
Ariel
2011/11/17 Erick Erickson
> Hmmm, I'm not seeing similar behavior on a trunk from today, when did
> you get your copy?
>
> Erick
>
> On Wed, Nov 16, 2011 at 2:06 PM, Ariel Zerbib
> wrote:
> > Hi,
> >
> > For this term proximity query: a
Hmmm, I'm not seeing similar behavior on a trunk from today, when did
you get your copy?
Erick
On Wed, Nov 16, 2011 at 2:06 PM, Ariel Zerbib wrote:
> Hi,
>
> For this term proximity query: ab_main_title_l0:"to be or not to be"~1000
>
> http://localhost:/solr/select?q=ab_main_title_l0%3A%22og
Hi,
For this term proximity query: ab_main_title_l0:"to be or not to be"~1000
http://localhost:/solr/select?q=ab_main_title_l0%3A%22og54ct8n+to+be+or+not+to+be+5w8ojsx2%22~1000&sort=score+desc&start=0&rows=3&fl=ab_main_title_l0%2Cscore%2Cid&debugQuery=true
The third first results are the fol
Of course, i did stop the solr before copying the index. Deleting
index and reindexing on production server did solve an issue. Strange,
but working..
> Have you stopped Solr before manually copying the data? This way you
> can be sure that index is the same and you didn't have any new docs
Have you stopped Solr before manually copying the data? This way you
can be sure that index is the same and you didn't have any new docs on
the fly.
2011/6/14 Denis Kuzmenok :
> What should i provide, OS is the same, environment is the same, solr
> is completely copied, searches work, excep
Well, you could provide the results with &debugQuery=on. You could
provide the schema.xml and solrconfig.xml files for both. You
could provide a listing of your index files. You could provide some
evidence that you've tried chasing down your problem using tools
like Luke or the Solr admin interface
What should i provide, OS is the same, environment is the same, solr
is completely copied, searches work, except that one, and that is
strange..
> I think you will need to provide more information than this, no-one on this
> list is omniscient AFAIK.
> François
> On Jun 14, 2011, at 10:
I think you will need to provide more information than this, no-one on this
list is omniscient AFAIK.
François
On Jun 14, 2011, at 10:44 AM, Denis Kuzmenok wrote:
> Hi.
>
> I've debugged search on test machine, after copying to production server
> the entire directory (entire solr director
Hi.
I've debugged search on test machine, after copying to production server
the entire directory (entire solr directory), i've noticed that one
query (SDR S70EE K) does match on test server, and does not on
production.
How can that be?
Hi Erik,
never mind.
Can't reproduce this strange behavior.
Obviously stopping and starting of solr solved this.
Thanks,
Bernd
Am 13.04.2011 16:00, schrieb Erik Hatcher:
What does the parsed query look like with debugQuery=true for both scenarios?
Any difference?
Doesn't make any
What does the parsed query look like with debugQuery=true for both scenarios?
Any difference? Doesn't make any sense that echoParams would have an effect,
unless somehow your search client is relying on parameters returned to do
something with them.?!
Erik
On Apr 13, 2011, at 09:57 ,
Dear list,
after setting "echoParams" to "none" wildcard search isn't working.
Only if I set "echoParams" to "explicit" then wildcard is possible.
http://wiki.apache.org/solr/CoreQueryParameters
states that "echoParams" is for debugging purposes.
We use Solr 3.1.0.
Snippet from solrconfig.xml:
Hi,
Thanks for your response. Attached are the Schema.xml and sample docs
that were indexed. The query and response are as below. The attachment
Prodsku4270257.xml has a field "paymenttype" whose value is 'prepaid'.
query:
q=prepaid&start=0&rows=10&fl=*%2Cscore&qt=standard&wt=json&debugQu
nformation.
regards,
Naga Ranjan
-Original Message-
From: RamaKrishna Atmakur [mailto:ramkrishn...@hotmail.com]
Sent: Thursday, May 13, 2010 5:57 AM
To: solr-user@lucene.apache.org
Subject: Strange behavior for certain words
Hi,
We are trying to use SOLR for searching our catalog
"time":0.0},
"org.apache.solr.handler.component.MoreLikeThisComponent":{
"time":0.0},
"org.apache.solr.handler.component.HighlightComponent":{
"time":0.0},
"org.apache.solr.handler.component.DebugComponent":{
"tim
Hmmm, there's not much information to go on here.
You might review this page:
http://wiki.apache.org/solr/UsingMailingLists
and post with more information. At minimum,
the field definitions, the query output (include
&debugQuery=on), perhaps what comes out
of the analysis admin page for both indexi
Hi,
We are trying to use SOLR for searching our catalog online and during QA
came across a interesting case where SOLR is not returning results that it
should.
Specificially, we have indexed things like "Title" and "Description", of the
words in the Title happens to be "Prepaid' and "Postpa
s, I see numDocs is approximately 470k (which
> >> is
> >> what I find strange) and maxDocs is approximately 890k (which is fine
> >> since
> >> I know I have around 700k duplicates). Even more confusing is that if I
> >> run
> >> this exact command
strange) and maxDocs is approximately 890k (which is fine
>> since
>> I know I have around 700k duplicates). Even more confusing is that if I
>> run
>> this exact command a second time without performing any other operations,
>> numDocs goes up to around 610k, and a third time brings it
e since
> I know I have around 700k duplicates). Even more confusing is that if I
> run
> this exact command a second time without performing any other operations,
> numDocs goes up to around 610k, and a third time brings it up to about
> 750k.
>
> Can anyone tell me what might ca
d third times?
I also have this line in solrconfig.xml, if it matters:
Thanks,
Dan
--
View this message in context:
http://old.nabble.com/Strange-Behavior-When-Using-CSVRequestHandler-tp27026926p27026926.html
Sent from the Solr - User mailing list archive at Nabble.com.
m: Funtick [mailto:f...@efendi.ca]
Sent: August-18-09 12:25 AM
To: solr-user@lucene.apache.org
Subject: Re: SOLR - extremely strange behavior! Documents
disappeared...
sorry for typo in prev msg,
Increase = 2,297,231 - 1,786,552 = 500,000 (average)
RATE (non-unique-id:unique-id) = 7,000,000 : 500,
; According to my own estimates, I should have about 10,000,000 new
>> documents now... I had 0.5 millions within an hour, and 0.8 mlns within a
>> day; same 'random' documents.
>>
>> This morning index size was about 4Gb, then suddenly dropped below 0.5
>
ns within an hour, and 0.8 mlns within a
> day; same 'random' documents.
>
> This morning index size was about 4Gb, then suddenly dropped below 0.5 Gb.
> Why? I haven't issued any "commit"...
>
> I am using ramBufferMB=8192
>
>
>
>
>
>>> According to my own estimates, I should have about 10,000,000 new
>>> documents
>>> now... I had 0.5 millions within an hour, and 0.8 mlns within a day;
>>> same
>>> 'random' documents.
>>>
>>> This morning index size was about 4
about 10,000,000 new
>> documents
>> now... I had 0.5 millions within an hour, and 0.8 mlns within a day; same
>> 'random' documents.
>>
>> This morning index size was about 4Gb, then suddenly dropped below 0.5
>> Gb.
>> Why? I haven't issued
.5 millions within an hour, and 0.8 mlns within a day; same
> 'random' documents.
>
> This morning index size was about 4Gb, then suddenly dropped below 0.5 Gb.
> Why? I haven't issued any "commit"...
>
> I am using ramBufferMB=8192
>
>
>
--
View this message in context:
http://www.nabble.com/SOLR-%3CuniqueKey%3E---extremely-strange-behavior%21-Documents-disappeared...-tp25017728p25017728.html
Sent from the Solr - User mailing list archive at Nabble.com.
PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
> > Try putting the stemmer after the lowercase filter.
> > -Yonik
> >
> > On Feb 12, 2008 9:15 AM, Traut <[EMAIL PROTECTED]> wrote:
> > > Hi all
> > >
> > > Please take a look at this
; Hi all
> >
> > Please take a look at this strange behavior (connected with stemming I
> > suppose):
> >
> >
> > type:
> >
> > > stored="false">
> >
> >
> >
> >
> >
Try putting the stemmer after the lowercase filter.
-Yonik
On Feb 12, 2008 9:15 AM, Traut <[EMAIL PROTECTED]> wrote:
> Hi all
>
> Please take a look at this strange behavior (connected with stemming I
> suppose):
>
>
&g
Hi all
Please take a look at this strange behavior (connected with stemming I
suppose):
type:
field:
I'm adding a document:
99Apple
Queriyng "name:apple" - 0 res
Thanks Ryan. I now know the reason why.
Before I explain the reason, let me correct the mistake I made in my earlier
mail. I was not using the first document mentioned in the xml . Instead it
was this one:
IW-02
iPod & iPod Mini USB 2.0 Cable
Belkin
electronics
connector
car power adap
1 - 100 of 116 matches
Mail list logo
