Jira issue: https://issues.apache.org/jira/browse/SOLR-6468
--
View this message in context:
http://lucene.472066.n3.nabble.com/Help-with-StopFilterFactory-tp4153839p4156373.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hello,
Any thoughts on this? Should I open a jira ticket? Or how can we engage at
least one of Solr devs to this issue?
Best,
Alex
--
View this message in context:
http://lucene.472066.n3.nabble.com/Help-with-StopFilterFactory-tp4153839p4155582.html
Sent from the Solr - User mailing list arch
The did:
>> If this behavior does not fit the application needs, the query parser
>> needs to be configured to not take position increments into account when
>> generating phrase queries.
Another one would be to write your own search engine maybe :)
--
View this message in context:
http://luce
2014 6:51 AM
To: solr-user@lucene.apache.org
Subject: Re: Help with StopFilterFactory
So it sounds like a bug to me, doesn't it? Interned is full of complaints
about this issue and why should all we suffer because of someone, who didn't
know when and how to use this feature and as result go
There is — admit that enablePositionIncrements removal was a bad idea and
restore it. Why to remove an option that has no alternatives because of
those who get wrong results with it? I really don't understand this
approach. And what should we do now, after spending lots of money on the
integration
: heaven
Sent: Tuesday, August 26, 2014 6:02 AM
To: solr-user@lucene.apache.org
Subject: Re: Help with StopFilterFactory
Hi, just tried your suggestion but get this error:
And then I found the next:
http://stackoverflow.com/questions/18668376/solr-4-4-stopfilterfactory-and-enablepositionincremen
So it sounds like a bug to me, doesn't it? Interned is full of complaints
about this issue and why should all we suffer because of someone, who didn't
know when and how to use this feature and as result got wrong data indexed?
Who cares about it??? And why to remove the option that is so useful for
Hi, just tried your suggestion but get this error:
And then I found the next:
http://stackoverflow.com/questions/18668376/solr-4-4-stopfilterfactory-and-enablepositionincrements.
I don't really know why they did so, the reason that "it can create broken
token streams" doesn't fit in my mind. Per
lr users is not well highlighted for Solr users. Sorry about that.
In any case, try adding enablePositionIncrements="false", reindex, and see
what happens.
-- Jack Krupansky
-Original Message-
From: heaven
Sent: Monday, August 25, 2014 3:37 AM
To: solr-user@lucene.apache.org
A valid search:
http://pastie.org/pastes/9500661/text?key=rgqj5ivlgsbk1jxsudx9za
An Invalid search:
http://pastie.org/pastes/9500662/text?key=b4zlh2oaxtikd8jvo5xaww
What weird I found is that the valid query has:
"parsedquery_toString": "+(url_words_ngram:\"twitter com zer0sleep\")"
And the invali
Sent: Sunday, August 24, 2014 12:47 PM
To: solr-user@lucene.apache.org
Subject: Re: Help with StopFilterFactory
The problem is in #4:
4. if I index twitter.com/testuser and search for
https://twitter.com/testuser I am getting 0 matches even though "https"
should be filtered out by the St
The problem is in #4:
>> 4. if I index twitter.com/testuser and search for
>> https://twitter.com/testuser I am getting 0 matches even though "https"
>> should be filtered out by the StopFilterFactory.
When I said that the stop filter factory "doesn't work" I mentioned that
blacklisted words still
rue query parameter and
post the parsed query so that we can see what was really generated for the
query.
-- Jack Krupansky
-Original Message-
From: heaven
Sent: Sunday, August 24, 2014 12:04 PM
To: solr-user@lucene.apache.org
Subject: Re: Help with StopFilterFactory
I don'
Just a guess but it seems that auto phase generation and stop filter factory
don't know of each other.
Here's the current field configuration:
{code}
{code}
--
View this message in context:
http://lucene.472066.n3.nabble.com/Help-with-StopFilter
I don't see any confusions, the problem is clearly explained in the first
post. The one confusion I had was with the autoGeneratePhraseQueries and my
schema version, I didn't know about that attribute and that its behavior
could differ per schema version. I think we now figured that out and I am
us
upansky
-Original Message-
From: heaven
Sent: Sunday, August 24, 2014 11:02 AM
To: solr-user@lucene.apache.org
Subject: Re: Help with StopFilterFactory
Unfortunately I can't change the operator and phrase query for
"https://twitter.com/testuser"; doesn't work as well.
Unfortunately I can't change the operator and phrase query for
"https://twitter.com/testuser"; doesn't work as well.
It does work for "twitter.com/testuser" but that makes no sense since I then
can simply use old schema version or autoGenereratePhaseQueries=true and ask
users to remove http/www fr
On 8/21/2014 9:52 AM, Shawn Heisey wrote:
> On 8/21/2014 8:40 AM, heaven wrote:
>> With 1.5 schema it work but not as it is expected. I am indexing
>> twitter.com/testuser and only need to get exact matches, not those that
>> match "twitter" or "com". so my search results should contain just one
>>
On 8/21/2014 8:40 AM, heaven wrote:
> With 1.5 schema it work but not as it is expected. I am indexing
> twitter.com/testuser and only need to get exact matches, not those that
> match "twitter" or "com". so my search results should contain just one
> record:
> * http://twitter.com/testuser
>
> but
With 1.5 schema it work but not as it is expected. I am indexing
twitter.com/testuser and only need to get exact matches, not those that
match "twitter" or "com". so my search results should contain just one
record:
* http://twitter.com/testuser
but what I see with 1.5 schema is:
* http://twitter.
@lucene.apache.org
Subject: Re: Help with StopFilterFactory
On 8/21/2014 7:25 AM, heaven wrote:
Any ideas? Doesn't that seems like a bug?
I think it should have worked even with autoGeneratePhraseQueries
enabled by the older schema version. The relative positions are the
same -- it's 1,
On 8/21/2014 7:25 AM, heaven wrote:
> Any ideas? Doesn't that seems like a bug?
I think it should have worked even with autoGeneratePhraseQueries
enabled by the older schema version. The relative positions are the
same -- it's 1,2,3 in the index and 2,3,4 in the query. Absolute
positions don't
Any ideas? Doesn't that seems like a bug?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Help-with-StopFilterFactory-tp4153839p4154202.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hello,
Yes, with schema version 1.5 all those examples that didn't work do work
now. But results also include records that match by "com", "twitter", etc,
which is not desirable.
It seems we do need autoGeneratePhraseQueries="true" but also need to ignore
blacklisted words. Is that somehow possi
>From this page: http://wiki.apache.org/solr/SchemaXml
>> autoGeneratePhraseQueries=true|false (in schema version 1.4 and later
>> this now defaults to false)
Just checked, I've so this may be true
by default?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Help-with-StopFi
> What release of Solr?
4.8.1.
> Do you have autoGeneratePhraseQueries="true" on the field?
No, the config I've provided is the exact.
> And when you said "But any of these does", did you mean "But NONE of these
does"?
Whoops, yes, fixed that.
--
View this message in context:
http://lucene.
What release of Solr?
Do you have autoGeneratePhraseQueries="true" on the field?
And when you said "But any of these does", did you mean "But NONE of these
does"?
-- Jack Krupansky
-Original Message-
From: heaven
Sent: Tuesday, August 19, 2014 2:34 PM
To: solr-user@lucene.apache.or
27 matches
Mail list logo
