On 4/27/07, Michael Pelz Sherman <[EMAIL PROTECTED]> wrote:
In our experience, setting a LowercaseFilter in the query did not work; we had
to call setLowercaseExpandedTerms(true) to get wildcard queries to be
case-insensitive.
Correct, because in that case the QueryParser does not invoke anal
In our experience, setting a LowercaseFilter in the query did not work; we had
to call setLowercaseExpandedTerms(true) to get wildcard queries to be
case-insensitive.
Here's our analyzer definition from our solr schema:
On 4/26/07, Michael Kimsal <[EMAIL PROTECTED]> wrote:
My colleague, after some digging, found in SolrQueryParser
(around line 62)
setLowercaseExpandedTerms(false);
The default for Lucene is true. Was this intentional? Or an oversight?
Way back before Solr was opensourced, and Chris
On 4/26/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
I think we should open up as many of the switches as we can to
QueryParser, allowing users to tinker with them if they want, setting
the defaults to the most common reasonable settings we can agree upon.
I think we should also try and handle w
on.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Michael Kimsal <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Friday, April 27, 2007 1:47:06 PM
Subject: Re: case sensitivity
What's the procedure then
What's the procedure then for something to get included in the next
release?
Thanks again all!
On 4/27/07, Michael Kimsal <[EMAIL PROTECTED]> wrote:
So I just create my own 'issue' first? OK. Thanks.
On 4/27/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>
> Michael Kimsal wrote:
> > Can you
So I just create my own 'issue' first? OK. Thanks.
On 4/27/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Michael Kimsal wrote:
> Can you point me to the process for submitting these small patches? I'm
> looking at the jira site but don't see much of anything there outlining
a
> process for su
Michael Kimsal wrote:
Can you point me to the process for submitting these small patches? I'm
looking at the jira site but don't see much of anything there outlining a
process for submitting patches. Sorry to be so basic about this, but I'm
trying to follow correct procedures on both sides of t
Can you point me to the process for submitting these small patches? I'm
looking at the jira site but don't see much of anything there outlining a
process for submitting patches. Sorry to be so basic about this, but I'm
trying to follow correct procedures on both sides of the aisle, so to speak.
On 4/26/07, Michael Kimsal <[EMAIL PROTECTED]> wrote:
We're (and by 'we' I mean my esteemed colleague!) working on patching a few
of these items to be in the solrconf.xml file and should likely have some
patches submitted next week. It's being done on 'company time' and I'm not
sure about the ex
We're (and by 'we' I mean my esteemed colleague!) working on patching a few
of these items to be in the solrconf.xml file and should likely have some
patches submitted next week. It's being done on 'company time' and I'm not
sure about the exact policy/procedure for this sort of thing here (or
in
On Apr 26, 2007, at 6:03 PM, Michael Kimsal wrote:
My colleague, after some digging, found in SolrQueryParser
(around line 62)
setLowercaseExpandedTerms(false);
The default for Lucene is true. Was this intentional? Or an
oversight?
I was just about to respond that this is likely the issu
My colleague, after some digging, found in SolrQueryParser
(around line 62)
setLowercaseExpandedTerms(false);
The default for Lucene is true. Was this intentional? Or an oversight?
Perhaps it's not related to my problem, but it seems that it might be.
Thanks in advance!
On 4/26/07, Michael
type:changelog AND ( ( (listing:Fox) or (listing:Fox*) or (listing:*Fox) ) )
and
type:changelog AND ( ( (listing:fox) or (listing:fox*) or (listing:*fox) ) )
Is this to do with the wildcards?
Actually, I've just answered my own question.
type:changelog AND ( ( (listing:fox) ) )
and
type:changel
I was just writing a followup.
I'm using the default text field type
That looks to me like it's got LowerCaseFilterFactory in the query analyzer
and t
On Apr 26, 2007, at 5:43 PM, Michael Kimsal wrote:
I've looked through the mailing lists and can't find much of anything
regarding case sensitivity. It
seems SOLR is case sensitive by default - I'm using the default
settings
with a very basic schema - just text fields.
All depends on the a
Oh, and yet another way to get around it (with it's own trade offs) is
to use something like fieldtype textTight in the example schema.xml,
which catenates all word parts in both the index analyzer and query
analyzer.
This would index as "upanddownmysitecom" and allow the following
queries to mat
On 12/13/06, Wade Leftwich <[EMAIL PROTECTED]> wrote:
I've run into some unexpected case sensitivity on searches, at least
unexpected by me.
If you index a text field containing this sentence:
A sentence containing CamelCase words by [EMAIL PROTECTED] is found
at StudlyCaps.org
The document wi
Also, avoid stemming URLs. I used a stemmer that turned my
"best.com" URL into "good.com". The Lucene StandardAnalyzer
works pretty hard to avoid that. --wunder
On 12/13/06 9:33 PM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote:
> When indexing (and searching), make sure you are using an Analyzer
When indexing (and searching), make sure you are using an Analyzer that
lower-cases (or upper-cases) tokens.
These are from Lucene, so Solr has them, too:
./src/java/org/apache/lucene/analysis/LowerCaseTokenizer.java
./src/java/org/apache/lucene/analysis/LowerCaseFilter.java
Otis
- Origi
20 matches
Mail list logo
