Re: "dismax" parameter "bq" filters instead of boosting

2019-04-16 Thread Alexandre Rafalovitch
If you set q.op=OR (and not as 'AND' you defined in your config), you
will see the difference between your last two queries. The second last
one will show 6 items and the last one still 5.

As is, with your custom config, booster query is added as one more
clause in the search. q.op=ALL forces it to be a compulsory clause,
rather than an optional (boosting one).

FQ is always a forced compulsory clause. Maybe it accepts boosts, but
all scores are ignored anyway (it is just 0 for fail and anything else
for pass).

Adding 'debug=all' into the query parameters (or defaults) would help
you see that for yourself.

But it does seem (in 7.2.1 I have here) that edismax seems to wrap
both query parts in individual brackets. Maybe there was a bug that
was fixed in eDismax only. No ideas there, except that most of the
effort goes into eDismax these days rather than dismax.

Regards,
   Alex
P.s. My suggestion was actually to give the queries against STOCK
examples. That would have made all these parameters explicit and more
obvious. And perhaps would have allowed you to discover the minimum
parameter set causing the issue without all those other qf and pf in
the game.

On Tue, 16 Apr 2019 at 16:13, Nicolas Franck  wrote:
>
> I agree, but I thought my thread was lost in the long list of issues.
>
> I prepared a simple case for solr 8.0:
>
>   basic_dismax_set/config:
>
>  schema.xml and solrconfig.xml
>
>   basic_dismax_set/data:
>
>  records_pp.json
>
>  Total 6 records:
>
> http://localhost:8983/solr/test/select?echoParams=all
>
>  5 records match format:book
>
> http://localhost:8983/solr/test/select?echoParams=all=format:book=lucene
>
> and 1 format:film
>
> http://localhost:8983/solr/test/select?echoParams=all=format:film=lucene
>
> But when I try this (defType is dismax) ..:
>
> http://localhost:8983/solr/test/select?echoParams=all=format:book^2
>
> the result list is filtered on format:book (total of 5 records)
>
> This url gives the same result by the way:
>
> http://localhost:8983/solr/test/select?echoParams=all=format:book^2
>
> while the character ^ isn't supposed to work in fq, right?
>
> The same result in both Solr 7.4.0 and Solr 8.0
>
> Thanks in advance
>


Re: autoGeneratePhraseQueries not working

2019-04-16 Thread Alexandre Rafalovitch
Ah oops. Did not realize the original text was missing spaces. Looked
like so many questions that did, I did not recheck the search query.

Go with Erick's explanation for this specific case. And keep my in
mind for input with spaces.

Regards,
   Alex.

On Tue, 16 Apr 2019 at 17:48, Erick Erickson  wrote:
>
> The issue isn’t SoW. What’s happening here is that the query _parser_ passes 
> my25word through as a single token, then WordDelimiterGraphFilterFactory 
> splits it up on number/letter changes after SoW is out of the picture. The 
> admin/analysis page will show you how this works.
>
> By fiddling with the settings in WordDelimiterGraphFilterFactory, you can get 
> close to auto phrase queries, in particular catenateall. But it’s not quite 
> the same thing under any circumstances as phrases.
>
> Best,
> Erick
>
> > On Apr 16, 2019, at 4:31 AM, Leonardo Francalanci 
> >  wrote:
> >
> > Thank you for the reply.
> > I'm using eDisMax, does it use the same parser as the Standard Query Parser 
> > then?
> > I think this behavior should be documented somehow... it's very confusing 
> > and to be honest I don't even remember how I got to the sow parameter... 
> > and I'm not sure what that means for all other queries I have
> >
> >Il martedì 16 aprile 2019, 13:09:26 CEST, Alexandre Rafalovitch 
> >  ha scritto:
> >
> > The issue is that the Standard Query Parser does pre-processing of the
> > query and splits it on whitespace beforehand (to deal with all the
> > special syntax). So, if you don't use quoted phrases then by the time
> > the field specific query analyzer chain kicks in, the text is already
> > pre-split and the analyzer only sees one (pre space-separated) token
> > at a time. So, the autoGeneratePhraseQueries does not work then. If
> > you use different parsers that send whole text in (e.g. FieldQParser),
> > then - I think - it will work.
> >
> > Or, like you discovered, sow=true tells the Standard Query Parser to
> > send it all together as well.
> >
> > It is a bit of a messy part of Solr, because the Admin Analysis page
> > sends the text to the query analyzer without splitting (it does not
> > use any Query Parser). So, that adds to the confusion.
> >
> > Regards,
> >   Alex.
> >
> > On Tue, 16 Apr 2019 at 10:53, Leonardo Francalanci
> >  wrote:
> >>
> >>   To add some information: using "sow=true" it seems to work.But I don't 
> >> understand why with "sow=false" it wouldn't work (can't find anything in 
> >> the docs about sow interaction with autoGeneratePhraseQueries); and the 
> >> implication of setting saw=true.
> >> I've found this:[SOLR-9185] Solr's edismax and "Lucene"/standard query 
> >> parsers should optionally not split on whitespace before sending terms to 
> >> analysis - ASF JIRA
> >>
> >> |
> >> |
> >> |  |
> >> [SOLR-9185] Solr's edismax and "Lucene"/standard query parsers should op...
> >>
> >>
> >>   |
> >>
> >>   |
> >>
> >>   |
> >>
> >>
> >> But it's very low level and I can't find any doc more "user friendly"
> >>
> >> Il martedì 16 aprile 2019, 09:00:08 CEST, Leonardo Francalanci 
> >>  ha scritto:
> >>
> >>   Hi,
> >>
> >> I'm using Solr 8.0.0  I can't get autoGeneratePhraseQueries to work (also 
> >> tried with 7.7.1 and same result):
> >>
> >> debug":{
> >> "rawquerystring":"TROUBLESHOOT:my25word",
> >> "querystring":"TROUBLESHOOT:my25word",
> >> "parsedquery":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
> >> "parsedquery_toString":"TROUBLESHOOT:my TROUBLESHOOT:25 
> >> TROUBLESHOOT:word",
> >>
> >> I expected something like
> >>
> >> "parsedquery":"TROUBLESHOOT:"my 25 word"
> >> Why isn't autoGeneratePhraseQueries generating a quoted string argument 
> >> when I query???
> >>
> >>
> >> This is my configuration:
> >>
> >>>> indexed="true"  stored="true"/>
> >>  >> positionIncrementGap="100" autoGeneratePhraseQueries="true">
> >>   
> >> 
> >> 
> >> 
> >>  >> ignoreCase="true"
> >> words="lang/stopwords_en.txt"
> >> />
> >>  >> generateWordParts="1" generateNumberParts="1" catenateWords="1" 
> >> catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
> >> 
> >>  >> protected="protwords.txt"/>
> >> 
> >> 
> >>   
> >>   
> >> 
> >>  >> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> >>  >> ignoreCase="true"
> >> words="lang/stopwords_en.txt"
> >> />
> >>  >> generateWordParts="1" generateNumberParts="1" catenateWords="0" 
> >> catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
> >> 
> >>  >> protected="protwords.txt"/>
> >> 
> >>   
> >> 
> >>  >> stored="true" multiValued="true" omitNorms="true"/>
> >>
>


SolrJ : Inserting Bean object containing different types of Child documents

2019-04-16 Thread Pratik Patel
Hello Everyone,

I have a Bean object which can have child documents of classes Child_type1
and Child_type2. When I try to index this document, I get an error message
"Doc cannot have more than one Field with child=true".

I looked at the mailing list but couldn't find any solution for this.
Any suggestions on how such documents should be indexed?

I am using SolrJ version 7.7.1 and Solr 7.4.0

Thanks!
Pratik


RE: Cannot set pollInterval in SolrCloud for PULL or TLOG replica

2019-04-16 Thread Vadim Ivanov
Hi, Dmitri
There was discussion here a while ago...
http://lucene.472066.n3.nabble.com/Soft-commit-and-new-replica-types-td4417253.html
May be it helps you somehow.

-- 
Vadim


> -Original Message-
> From: Dmitry Vorotilin [mailto:d.voroti...@gmail.com]
> Sent: Tuesday, April 16, 2019 9:41 AM
> To: solr-user@lucene.apache.org
> Subject: Cannot set pollInterval in SolrCloud for PULL or TLOG replica
> 
> Hi everyone,
> 
> We have SolrCloud cluster with 3 zk and 3 solr nodes. It's 1 shard only and
> all replicas are PULL.
> We have bulk updates so like once a day we reindex all cores (no soft
> commits, only hard commit every 15s), do commit with openSearcher=true
> and
> all our indexes become available for search.
> 
> The issue is that for PULL replication when leader reindexing starts it
> downloads index every
> hard commit / 2 seconds (o.a.s.h.ReplicationHandler Poll scheduled at an
> interval of 7000ms) then puts index into proper directory and just reopens
> searcher so that we see no changes on leader because there was no commit
> with openSearcher=true yet and that index keeps growing on PULL replicas.
> 
> Judging by this page
>  replication-in-solr>
> there's no setting for pollInterval or when to start replication on slaves
> in SolrCloud and the info is rather confusing because in cloud we still use
> the same handlers which we cannot configure.
> 
> We changed replication from NRT to PULL because we don't need realtime
> and
> burn CPU with bulk updates on every machine, but this constantly catching
> up index on slaves isn't any better...
> 
> Do you know any way to fix it?



Re: JSON Facet query to retrieve count all collections in Solr 8.0.0

2019-04-16 Thread Jason Gerlowski
Hi Edwin,

To clarify what you're running into:

- on 7.6, this query works all the time
- on 7.7 this query works all the time
- on 8.0, this query works the first time you run it, but subsequent
runs return a 401 error?

Is that correct?  It might be helpful for others if you could share
your security.json.

Best,

Jason

On Mon, Apr 15, 2019 at 10:40 PM Zheng Lin Edwin Yeo
 wrote:
>
> Hi,
>
> I am using the below JSON Facet to retrieve the count of all the different
> collections in one query.
>
> https://localhost:8983/solr/collection1/select?q=testing=https://localhost:8983/solr/collection1,https://localhost:8983/solr/collection2,https://localhost:8983/solr/collection3,https://localhost:8983/solr/collection4,https://localhost:8983/solr/collection5,https://localhost:8983/solr/collection6=0={categories
> : {type : terms,field : content_type,limit : 100}}
>
>
> Previously, in Solr 7.6 and Solr 7.7, this query can work correctly and we
> are able to produce the correct output.
>
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":24},
>   "response":{"numFound":41200,"start":0,"maxScore":12.993215,"docs":[]
>   },
>   "facets":{
> "count":41200,
> "categories":{
>   "buckets":[{
>   "val":"collection1",
>   "count":26213},
> {
>   "val":"collection2",
>   "count":12075},
> {
>   "val":"collection3",
>   "count":1947},
> {
>   "val":"collection4",
>   "count":850},
> {
>   "val":"collection5",
>   "count":111},
> {
>   "val":"collection6",
>   "count":4}]}}}
>
>
> However, in the new Solr 8.0.0, this query can only work once.
> Subsequently, we will get the following error of 'require authentication':
>
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":401,
> "QTime":11},
>   "error":{
> "metadata":[
>
> "error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException",
>
> "root-error-class","org.apache.solr.client.solrj.impl.Http2SolrClient$RemoteSolrException"],
> "msg":"Error from server at null: Expected mime type
> application/octet-stream but got text/html. \n\n http-equiv=\"Content-Type\"
> content=\"text/html;charset=utf-8\"/>\nError 401 require
> authentication\n\nHTTP ERROR 401\nProblem
> accessing /solr/collection6/select. Reason:\nrequire
> authentication\n\n\n",
> "code":401}}
>
> This issue does not occur in Solr 7.6 and Solr 7.7, even though I have set
> up the same authentication for all the versions.
>
> What could be the issue that causes this?
>
> Regards,
> Edwin


Re: autoGeneratePhraseQueries not working

2019-04-16 Thread Erick Erickson
The issue isn’t SoW. What’s happening here is that the query _parser_ passes 
my25word through as a single token, then WordDelimiterGraphFilterFactory splits 
it up on number/letter changes after SoW is out of the picture. The 
admin/analysis page will show you how this works.

By fiddling with the settings in WordDelimiterGraphFilterFactory, you can get 
close to auto phrase queries, in particular catenateall. But it’s not quite the 
same thing under any circumstances as phrases.

Best,
Erick

> On Apr 16, 2019, at 4:31 AM, Leonardo Francalanci 
>  wrote:
> 
> Thank you for the reply.
> I'm using eDisMax, does it use the same parser as the Standard Query Parser 
> then?
> I think this behavior should be documented somehow... it's very confusing and 
> to be honest I don't even remember how I got to the sow parameter... and I'm 
> not sure what that means for all other queries I have
> 
>Il martedì 16 aprile 2019, 13:09:26 CEST, Alexandre Rafalovitch 
>  ha scritto:  
> 
> The issue is that the Standard Query Parser does pre-processing of the
> query and splits it on whitespace beforehand (to deal with all the
> special syntax). So, if you don't use quoted phrases then by the time
> the field specific query analyzer chain kicks in, the text is already
> pre-split and the analyzer only sees one (pre space-separated) token
> at a time. So, the autoGeneratePhraseQueries does not work then. If
> you use different parsers that send whole text in (e.g. FieldQParser),
> then - I think - it will work.
> 
> Or, like you discovered, sow=true tells the Standard Query Parser to
> send it all together as well.
> 
> It is a bit of a messy part of Solr, because the Admin Analysis page
> sends the text to the query analyzer without splitting (it does not
> use any Query Parser). So, that adds to the confusion.
> 
> Regards,
>   Alex.
> 
> On Tue, 16 Apr 2019 at 10:53, Leonardo Francalanci
>  wrote:
>> 
>>   To add some information: using "sow=true" it seems to work.But I don't 
>> understand why with "sow=false" it wouldn't work (can't find anything in the 
>> docs about sow interaction with autoGeneratePhraseQueries); and the 
>> implication of setting saw=true.
>> I've found this:[SOLR-9185] Solr's edismax and "Lucene"/standard query 
>> parsers should optionally not split on whitespace before sending terms to 
>> analysis - ASF JIRA
>> 
>> |
>> |
>> |  |
>> [SOLR-9185] Solr's edismax and "Lucene"/standard query parsers should op...
>> 
>> 
>>   |
>> 
>>   |
>> 
>>   |
>> 
>> 
>> But it's very low level and I can't find any doc more "user friendly"
>> 
>> Il martedì 16 aprile 2019, 09:00:08 CEST, Leonardo Francalanci 
>>  ha scritto:
>> 
>>   Hi,
>> 
>> I'm using Solr 8.0.0  I can't get autoGeneratePhraseQueries to work (also 
>> tried with 7.7.1 and same result):
>> 
>> debug":{
>> "rawquerystring":"TROUBLESHOOT:my25word",
>> "querystring":"TROUBLESHOOT:my25word",
>> "parsedquery":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
>> "parsedquery_toString":"TROUBLESHOOT:my TROUBLESHOOT:25 
>> TROUBLESHOOT:word",
>> 
>> I expected something like
>> 
>> "parsedquery":"TROUBLESHOOT:"my 25 word"
>> Why isn't autoGeneratePhraseQueries generating a quoted string argument when 
>> I query???
>> 
>> 
>> This is my configuration:
>> 
>>   > indexed="true"  stored="true"/>
>> > positionIncrementGap="100" autoGeneratePhraseQueries="true">
>>   
>> 
>> 
>> 
>> > ignoreCase="true"
>> words="lang/stopwords_en.txt"
>> />
>> > generateWordParts="1" generateNumberParts="1" catenateWords="1" 
>> catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
>> 
>> > protected="protwords.txt"/>
>> 
>> 
>>   
>>   
>> 
>> > synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>> > ignoreCase="true"
>> words="lang/stopwords_en.txt"
>> />
>> > generateWordParts="1" generateNumberParts="1" catenateWords="0" 
>> catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
>> 
>> > protected="protwords.txt"/>
>> 
>>   
>> 
>> > stored="true" multiValued="true" omitNorms="true"/>
>> 



Re: Deleting a field in schema.xml, reindex needed?

2019-04-16 Thread Erick Erickson
“Throws an error” is not very informative. _What_ error?

In general reindexing should not be required. This is often a result of trying 
to _use_ the field for something. Take a careful look at the error, that may 
give a clue.

Best,
Erick

> On Apr 16, 2019, at 6:00 AM, Hema Preetha  wrote:
> 
> Hi - Did you find any solution for this. Because am also facing the same
> problem. After removing the field, it throws an error while doing full
> index. And also the index gets failed.
> 
> Regards,
> H P
> 
> 
> 
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html



Re: Solr numFound > 0 but doc list empty in Solr Cloud setup

2019-04-16 Thread Christian Strohmaier
I came across this posting with exactly the same symptoms in my solr cloud.

Here is what finally repaired my system:
I had an id with fieldType class="solr.TextField"
I changed this to class="solr.StrField"

Best regards
Christian 



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Re: Deleting a field in schema.xml, reindex needed?

2019-04-16 Thread Hema Preetha
Hi - Did you find any solution for this. Because am also facing the same
problem. After removing the field, it throws an error while doing full
index. And also the index gets failed.

Regards,
H P



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Re: "dismax" parameter "bq" filters instead of boosting

2019-04-16 Thread Nicolas Franck
I agree, but I thought my thread was lost in the long list of issues.

I prepared a simple case for solr 8.0:

  basic_dismax_set/config:

 schema.xml and solrconfig.xml

  basic_dismax_set/data:

 records_pp.json

 Total 6 records:

http://localhost:8983/solr/test/select?echoParams=all

 5 records match format:book

http://localhost:8983/solr/test/select?echoParams=all=format:book=lucene

and 1 format:film

http://localhost:8983/solr/test/select?echoParams=all=format:film=lucene

But when I try this (defType is dismax) ..:

http://localhost:8983/solr/test/select?echoParams=all=format:book^2

the result list is filtered on format:book (total of 5 records)

This url gives the same result by the way:

http://localhost:8983/solr/test/select?echoParams=all=format:book^2

while the character ^ isn't supposed to work in fq, right?

The same result in both Solr 7.4.0 and Solr 8.0

Thanks in advance

<>


Re: autoGeneratePhraseQueries not working

2019-04-16 Thread Leonardo Francalanci
 Thank you for the reply.
I'm using eDisMax, does it use the same parser as the Standard Query Parser 
then?
I think this behavior should be documented somehow... it's very confusing and 
to be honest I don't even remember how I got to the sow parameter... and I'm 
not sure what that means for all other queries I have

Il martedì 16 aprile 2019, 13:09:26 CEST, Alexandre Rafalovitch 
 ha scritto:  
 
 The issue is that the Standard Query Parser does pre-processing of the
query and splits it on whitespace beforehand (to deal with all the
special syntax). So, if you don't use quoted phrases then by the time
the field specific query analyzer chain kicks in, the text is already
pre-split and the analyzer only sees one (pre space-separated) token
at a time. So, the autoGeneratePhraseQueries does not work then. If
you use different parsers that send whole text in (e.g. FieldQParser),
then - I think - it will work.

Or, like you discovered, sow=true tells the Standard Query Parser to
send it all together as well.

It is a bit of a messy part of Solr, because the Admin Analysis page
sends the text to the query analyzer without splitting (it does not
use any Query Parser). So, that adds to the confusion.

Regards,
  Alex.

On Tue, 16 Apr 2019 at 10:53, Leonardo Francalanci
 wrote:
>
>  To add some information: using "sow=true" it seems to work.But I don't 
>understand why with "sow=false" it wouldn't work (can't find anything in the 
>docs about sow interaction with autoGeneratePhraseQueries); and the 
>implication of setting saw=true.
> I've found this:[SOLR-9185] Solr's edismax and "Lucene"/standard query 
> parsers should optionally not split on whitespace before sending terms to 
> analysis - ASF JIRA
>
> |
> |
> |  |
> [SOLR-9185] Solr's edismax and "Lucene"/standard query parsers should op...
>
>
>  |
>
>  |
>
>  |
>
>
> But it's very low level and I can't find any doc more "user friendly"
>
>    Il martedì 16 aprile 2019, 09:00:08 CEST, Leonardo Francalanci 
> ha scritto:
>
>  Hi,
>
> I'm using Solr 8.0.0  I can't get autoGeneratePhraseQueries to work (also 
> tried with 7.7.1 and same result):
>
> debug":{
>    "rawquerystring":"TROUBLESHOOT:my25word",
>    "querystring":"TROUBLESHOOT:my25word",
>    "parsedquery":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
>    "parsedquery_toString":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
>
> I expected something like
>
> "parsedquery":"TROUBLESHOOT:"my 25 word"
> Why isn't autoGeneratePhraseQueries generating a quoted string argument when 
> I query???
>
>
> This is my configuration:
>
>      indexed="true"  stored="true"/>
>    positionIncrementGap="100" autoGeneratePhraseQueries="true">
>      
>        
>        
>        
>                        ignoreCase="true"
>                words="lang/stopwords_en.txt"
>        />
>        generateWordParts="1" generateNumberParts="1" catenateWords="1" 
>catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
>        
>        protected="protwords.txt"/>
>        
>        
>      
>      
>        
>        ignoreCase="true" expand="true"/>
>                        ignoreCase="true"
>                words="lang/stopwords_en.txt"
>        />
>        generateWordParts="1" generateNumberParts="1" catenateWords="0" 
>catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
>        
>        protected="protwords.txt"/>
>        
>      
>    
>  stored="true" multiValued="true" omitNorms="true"/>
>
>  

Re: "dismax" parameter "bq" filters instead of boosting

2019-04-16 Thread Alexandre Rafalovitch
That's a bit "fast" to expect somebody to reproduce this from
information given. Or even in general to check the mailing list, given
that we are not paid support :-)

Could you please
1) Download the latest 8.0 distribution
2) Do one of the basic examples
3) Give the search query that shows before/after BQ
4) Bonus points: test the same thing in 7.4 again with the same example

This allows somebody to reproduce the situation exactly without
wondering if it was something already fixed after 7.4, or an issue in
your example or something else.

Regards,
   Alex.

On Tue, 16 Apr 2019 at 13:17, Nicolas Franck  wrote:
>
> any update on this?
>
> > On 5 Mar 2019, at 09:06, Nicolas Franck  wrote:
> >
> > I noticed a change in the behaviour of the regular "dismax" parser.
> > At least in version 7.4:
> >
> > when you add "bq", it filters the results (like "fq" does), instead of 
> > boosting the matches.
> >
> >
> > e.g.
> >
> > defType=dismax
> > bq=format:periodical^30
> >
> > gives only records with format "periodical".
> > removing the parameter "bq" returns all records
> >
> > It does work when defType is set to "edismax".
> >
> > Any idea?
>


Re: autoGeneratePhraseQueries not working

2019-04-16 Thread Alexandre Rafalovitch
The issue is that the Standard Query Parser does pre-processing of the
query and splits it on whitespace beforehand (to deal with all the
special syntax). So, if you don't use quoted phrases then by the time
the field specific query analyzer chain kicks in, the text is already
pre-split and the analyzer only sees one (pre space-separated) token
at a time. So, the autoGeneratePhraseQueries does not work then. If
you use different parsers that send whole text in (e.g. FieldQParser),
then - I think - it will work.

Or, like you discovered, sow=true tells the Standard Query Parser to
send it all together as well.

It is a bit of a messy part of Solr, because the Admin Analysis page
sends the text to the query analyzer without splitting (it does not
use any Query Parser). So, that adds to the confusion.

Regards,
   Alex.

On Tue, 16 Apr 2019 at 10:53, Leonardo Francalanci
 wrote:
>
>  To add some information: using "sow=true" it seems to work.But I don't 
> understand why with "sow=false" it wouldn't work (can't find anything in the 
> docs about sow interaction with autoGeneratePhraseQueries); and the 
> implication of setting saw=true.
> I've found this:[SOLR-9185] Solr's edismax and "Lucene"/standard query 
> parsers should optionally not split on whitespace before sending terms to 
> analysis - ASF JIRA
>
> |
> |
> |  |
> [SOLR-9185] Solr's edismax and "Lucene"/standard query parsers should op...
>
>
>  |
>
>  |
>
>  |
>
>
> But it's very low level and I can't find any doc more "user friendly"
>
> Il martedì 16 aprile 2019, 09:00:08 CEST, Leonardo Francalanci 
>  ha scritto:
>
>  Hi,
>
> I'm using Solr 8.0.0  I can't get autoGeneratePhraseQueries to work (also 
> tried with 7.7.1 and same result):
>
> debug":{
> "rawquerystring":"TROUBLESHOOT:my25word",
> "querystring":"TROUBLESHOOT:my25word",
> "parsedquery":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
> "parsedquery_toString":"TROUBLESHOOT:my TROUBLESHOOT:25 
> TROUBLESHOOT:word",
>
> I expected something like
>
> "parsedquery":"TROUBLESHOOT:"my 25 word"
> Why isn't autoGeneratePhraseQueries generating a quoted string argument when 
> I query???
>
>
> This is my configuration:
>
>indexed="true"  stored="true"/>
>  positionIncrementGap="100" autoGeneratePhraseQueries="true">
>   
> 
> 
> 
>  ignoreCase="true"
> words="lang/stopwords_en.txt"
> />
>  generateWordParts="1" generateNumberParts="1" catenateWords="1" 
> catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>
> 
>  protected="protwords.txt"/>
> 
> 
>   
>   
> 
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>  ignoreCase="true"
> words="lang/stopwords_en.txt"
> />
>  generateWordParts="1" generateNumberParts="1" catenateWords="0" 
> catenateNumbers="0" catenateAll="0" splitOnCaseChange="1"/>
> 
>  protected="protwords.txt"/>
> 
>   
> 
>  stored="true" multiValued="true" omitNorms="true"/>
>
>


Re: "dismax" parameter "bq" filters instead of boosting

2019-04-16 Thread Nicolas Franck
any update on this?

> On 5 Mar 2019, at 09:06, Nicolas Franck  wrote:
> 
> I noticed a change in the behaviour of the regular "dismax" parser.
> At least in version 7.4:
> 
> when you add "bq", it filters the results (like "fq" does), instead of 
> boosting the matches.
> 
> 
> e.g.
> 
> defType=dismax
> bq=format:periodical^30
> 
> gives only records with format "periodical".
> removing the parameter "bq" returns all records
> 
> It does work when defType is set to "edismax".
> 
> Any idea?



Re: autoGeneratePhraseQueries not working

2019-04-16 Thread Leonardo Francalanci
 To add some information: using "sow=true" it seems to work.But I don't 
understand why with "sow=false" it wouldn't work (can't find anything in the 
docs about sow interaction with autoGeneratePhraseQueries); and the implication 
of setting saw=true.
I've found this:[SOLR-9185] Solr's edismax and "Lucene"/standard query parsers 
should optionally not split on whitespace before sending terms to analysis - 
ASF JIRA

| 
| 
|  | 
[SOLR-9185] Solr's edismax and "Lucene"/standard query parsers should op...


 |

 |

 |


But it's very low level and I can't find any doc more "user friendly"

Il martedì 16 aprile 2019, 09:00:08 CEST, Leonardo Francalanci 
 ha scritto:  
 
 Hi,

I'm using Solr 8.0.0  I can't get autoGeneratePhraseQueries to work (also tried 
with 7.7.1 and same result):

debug":{
    "rawquerystring":"TROUBLESHOOT:my25word",
    "querystring":"TROUBLESHOOT:my25word",
    "parsedquery":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
    "parsedquery_toString":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",

I expected something like

"parsedquery":"TROUBLESHOOT:"my 25 word"
Why isn't autoGeneratePhraseQueries generating a quoted string argument when I 
query???


This is my configuration:

  
    
  
    
    
    
    
    
    
    
    
    
  
  
    
    
    
    
    
    
    
  
    


  

autoGeneratePhraseQueries not working

2019-04-16 Thread Leonardo Francalanci
Hi,

I'm using Solr 8.0.0  I can't get autoGeneratePhraseQueries to work (also tried 
with 7.7.1 and same result):

debug":{
    "rawquerystring":"TROUBLESHOOT:my25word",
    "querystring":"TROUBLESHOOT:my25word",
    "parsedquery":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",
    "parsedquery_toString":"TROUBLESHOOT:my TROUBLESHOOT:25 TROUBLESHOOT:word",

I expected something like

"parsedquery":"TROUBLESHOOT:"my 25 word"
Why isn't autoGeneratePhraseQueries generating a quoted string argument when I 
query???


This is my configuration:

  
    
  
    
    
    
    
    
    
    
    
    
  
  
    
    
    
    
    
    
    
  
    





Cannot set pollInterval in SolrCloud for PULL or TLOG replica

2019-04-16 Thread Dmitry Vorotilin
Hi everyone,

We have SolrCloud cluster with 3 zk and 3 solr nodes. It's 1 shard only and
all replicas are PULL.
We have bulk updates so like once a day we reindex all cores (no soft
commits, only hard commit every 15s), do commit with openSearcher=true and
all our indexes become available for search.

The issue is that for PULL replication when leader reindexing starts it
downloads index every
hard commit / 2 seconds (o.a.s.h.ReplicationHandler Poll scheduled at an
interval of 7000ms) then puts index into proper directory and just reopens
searcher so that we see no changes on leader because there was no commit
with openSearcher=true yet and that index keeps growing on PULL replicas.

Judging by this page

there's no setting for pollInterval or when to start replication on slaves
in SolrCloud and the info is rather confusing because in cloud we still use
the same handlers which we cannot configure.

We changed replication from NRT to PULL because we don't need realtime and
burn CPU with bulk updates on every machine, but this constantly catching
up index on slaves isn't any better...

Do you know any way to fix it?