Hi Bernd,
I was referring to assessing 5.5's behaviour based on a comparison to 4.10
when giving it that same inputs and configuration. Maybe I am wrong, and I
apologise if so. I am only seeing fragments of the situation each time, so
it is hard to be sure. Certainly in this case it looks like a c
We need to get this fixed.
Do you have some sample queries?
On Wed, Sep 14, 2016 at 12:37 AM, Bernd Fehling <
bernd.fehl...@uni-bielefeld.de> wrote:
> Hi Greg,
>
> after trying several hours with all combinations of parameters and not
> getting any useful search result with complex search terms
Your statement "using the old behaviour as a baseline for checking the
correctness of 5.5 behaviour" might be a point of view.
Let me give an example, my query:
q=(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
results to 159 hits from 99 million records in the index (version 4.
On Sun, Sep 11, 2016 at 11:29 PM, Greg Pendlebury
wrote:
> I'm not certain what is going on with your boost. It doesn't seem related
> to those tickets as far as I can see, but I note it comes back in the
> 'parsedquery_toString' step below that. Perhaps the debug output has a
> display bug?
Yeah
I'm sorry that's been your experience Bernd. If you do manage to find some
time it would be good to see some details on these bugs. It looks at the
moment as though this is a matter of perception when using the old
behaviour as a baseline for checking the correctness of 5.5 behaviour.
Ta,
Greg
O
Perhaps https://issues.apache.org/jira/browse/SOLR-8812 and related?
Best,
Erick
On Tue, Sep 13, 2016 at 11:37 PM, Bernd Fehling
wrote:
> Hi Greg,
>
> after trying several hours with all combinations of parameters and not
> getting any useful search result with complex search terms and edismax
>
Hi Greg,
after trying several hours with all combinations of parameters and not
getting any useful search result with complex search terms and edismax
I finally copied o.a.s.s.ExtendedDismaxQParser.java from version 4.10.4
to 5.5.3 and did a little modification in o.a.s.u.SolrPluginUtils.java.
No
I'm not certain what is going on with your boost. It doesn't seem related
to those tickets as far as I can see, but I note it comes back in the
'parsedquery_toString' step below that. Perhaps the debug output has a
display bug?
The fact that 4.10 was not applying 'mm' in this context relates the o
Hi Bernd,
"From my point of view the old parsing behavior was correct.
If searching for a term without operator it is always OR, otherwise
you can add "+" or "-" to modify that. Now with q.op AND it is
modified to "+" as a MUST."
It is correct in both cases. q.op dictates (for that query) what de
After some more testing it feels like the parsing in 5.5.3 is _really_ messed
up.
Query version 4.10.4:
(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
(+(((+text:star +text:trek +text:war)^200.0) Ph
Hi Greg,
thanks a lot, thats it.
After setting q.op to OR it works _nearly_ as before with 4.10.4.
But how stupid this?
I have in my schema
and also had q.op to AND to make sure my default _is_ AND,
meant as conjunction between terms.
But now I have q.op to OR and defaultOperator in schema to AN
I forgot to mention the tickets:
SOLR-2649 and SOLR-8812
On 9 September 2016 at 13:38, Greg Pendlebury
wrote:
> Under 4.10 q.op was ignored by the edismax parser and always forced to OR.
> 5.5 is looking at the q.op=AND you requested.
>
> There are also some changes to the default values selecte
Under 4.10 q.op was ignored by the edismax parser and always forced to OR.
5.5 is looking at the q.op=AND you requested.
There are also some changes to the default values selected for mm, but I
doubt those apply here since you are setting it explicitly.
On 8 September 2016 at 00:35, Mikhail Khlud
I suppose
+((text:star text:trek)~2)
and
+(+text:star +text:trek)
are equal. mm=2 is equal to +foo +bar
On Wed, Sep 7, 2016 at 10:52 AM, Bernd Fehling <
bernd.fehl...@uni-bielefeld.de> wrote:
> Hi list,
>
> while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query parsing.
> 4.10.4
>
It is Extended DisMax.
explicit
xml
edismax
*:*
*:*
AND
100%
10
text
6
fcs
6
Must be something in solr.ExtendedDismaxQParser or lucene.BooleanQuery
Regards,
Bernd
Am 07.09.2016 um 13:22 schrieb Ahmet Arslan:
> Hi,
>
> The tilde
Hi,
The tilde in the former looks interesting.
I think it related to proximity search.
What query parser is this?
Ahmet
On Wednesday, September 7, 2016 10:52 AM, Bernd Fehling
wrote:
Hi list,
while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query parsing.
4.10.4
text:star text:
Hi list,
while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query parsing.
4.10.4
text:star text:trek
text:star text:trek
(+((text:star text:trek)~2))/no_coord
+((text:star text:trek)~2)
5.5.3
text:star text:trek
text:star text:trek
(+(+text:star +text:trek))/no_coord
+(+text
17 matches
Mail list logo
