My schema.xml currently has a content field and a content_rev field
which is the field run through the reversed wild card filter, my
question is does Edismax support using this field? Reading through
this jira(https://issues.apache.org/jira/browse/SOLR-1321) it seems to
indicate that SolrQueryPars
apache.org/jira/browse/SOLR-218
Bill
On Nov 12, 2007 10:25 AM, Traut <[EMAIL PROTECTED]> wrote:
Hi
I found the thread about enabling leading wildcards in
Solr as additional option in config file. I've got nightly Solr build
and I can't find any options conne
owse/SOLR-218
Bill
On Nov 12, 2007 10:25 AM, Traut <[EMAIL PROTECTED]> wrote:
Hi
I found the thread about enabling leading wildcards in
Solr as additional option in config file. I've got nightly Solr build
and I can't find any options connected with leading wil
e.org/jira/browse/SOLR-218
> >
> > Bill
> >
> > On Nov 12, 2007 10:25 AM, Traut <[EMAIL PROTECTED]> wrote:
> > > Hi
> > > I found the thread about enabling leading wildcards in
> > > Solr as additional option in config file. I&#
007 10:25 AM, Traut <[EMAIL PROTECTED]> wrote:
> > Hi
> > I found the thread about enabling leading wildcards in
> > Solr as additional option in config file. I've got nightly Solr build
> > and I can't find any options connected with leading wildcards
The related bug is still open:
http://issues.apache.org/jira/browse/SOLR-218
Bill
On Nov 12, 2007 10:25 AM, Traut <[EMAIL PROTECTED]> wrote:
> Hi
> I found the thread about enabling leading wildcards in
> Solr as additional option in config file. I've got nightl
Hi
I found the thread about enabling leading wildcards in
Solr as additional option in config file. I've got nightly Solr build
and I can't find any options connected with leading wildcards in
config files.
How I can enable leading wildcard queries in Solr?
ROTECTED] list.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Michael Pelz Sherman
To: solr-user@lucene.apache.org
Sent: Wednesday, May 2, 2007 12:11:45 PM
Subject: Re: Leading wildcards
Try it on the nightly
ist.
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
- Original Message
From: Michael Pelz Sherman <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Wednesday, May 2, 2007 12:11:45 PM
Subject: Re: Leading wildcards
Try i
Share
- Original Message
From: Michael Pelz Sherman
To: solr-user@lucene.apache.org
Sent: Wednesday, May 2, 2007 10:52:53 AM
Subject: Re: Leading wildcards
I just downloaded the latest nightly build of Lucene and compiled it with the
solr 1.1.0 source, and now leading + trailing wildcards work
- Share
- Original Message
From: Michael Pelz Sherman <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Wednesday, May 2, 2007 10:52:53 AM
Subject: Re: Leading wildcards
I just downloaded the latest nightly build of Lucene and compiled it with the
solr 1.1.0 source, and now l
I just downloaded the latest nightly build of Lucene and compiled it with the
solr 1.1.0 source, and now leading + trailing wildcards work like a charm.
The only issue is, the lucene-core .jar file seems to have a runtime
dependency on clover.jar. Does anyone know if this is intentional, or
Just cant figure this out, ...or do I have to do this programmatically?
Have a facet, and field in an document called estimatedRepairs, it is
declared in the schema.xml as
I execute a query with the below parameters
q=state%3Avirgina;
&facet.query=estimatedRepairs:[*+TO+1000.0]
&fa
<[EMAIL PROTECTED]>
Reply-To: solr-user@lucene.apache.org
To: solr-user@lucene.apache.org
Subject: Re: AW: Leading wildcards
Date: Fri, 27 Apr 2007 16:25:37 -0700 (PDT)
: when we do a search on a nonexisting field, we get a SolrException:
: undefined field
: (this was for query "no
: when we do a search on a nonexisting field, we get a SolrException:
: undefined field
: (this was for query "nonfield:test")
:
: but when we use wildcards in our query, we dont get the undefined field
: exception,
: so the query "nonfield:*test" works fine ... just zero results...
:
: is this n
Here is a late response, apache.org was rejecting our e-mails...
Allowing leading wildcards opens up a denial of service attack. It becomes
trivial to overload the search engine and take it out of service, just
hammer it with leading wildcard queries. Please leave the default as
disabled. If we
hey,
we've stumbled on something weird while using wildcards
we enabled leading wildcards in solr (see previous message from Christian
Burkamp)
when we do a search on a nonexisting field, we get a SolrException:
undefined field
(this was for query "nonfield:test")
but when w
moment.
grts,m
"Michael Kimsal" <[EMAIL PROTECTED]>
20/04/2007 16:30
Please respond to
solr-user@lucene.apache.org
To
solr-user@lucene.apache.org
cc
Subject
Re: AW: Leading wildcards
Maarten:
Would you mind sharing your custom query parser?
On 4/20/07, [EMAIL PROTECTED] &
ve a nice weekend,
maarten
"Burkamp, Christian" <[EMAIL PROTECTED]>
19/04/2007 12:37
Please respond to
solr-user@lucene.apache.org
To
cc
Subject
AW: Leading wildcards
Hi there,
Solr does not support leading wildcards, because it uses Lucene's standard
QueryPars
solr-user@lucene.apache.org
To
cc
Subject
AW: Leading wildcards
Hi there,
Solr does not support leading wildcards, because it uses Lucene's standard
QueryParser class without changing the defaults. You can easily change
this by inserting the line
parser.setAllowLeadingWildcards(tr
: > i don't know that this is really dding a feature ... it's changing syntax.
: > "foo:*bar" has meaning by default in the query parser ... it's meaning may
: > typically result in a query that doesn't match anything,
:
: I think it's adding syntax, not changing it.
: Right now, you get an except
On 4/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: For things that return results, yes. I think that taking away
: features isn't a good thing, but adding them can be (basically,
: backward compatibility).
i don't know that this is really dding a feature ... it's changing syntax.
"foo:*ba
: > ConstantScorePrefixQuery is used... there shouldn't be an issue with
: > memory, just time.
:
: Oops, except we aren't always talking about a prefix query.
: I know at least some expanding queries automatically limit to the max
: number of boolean clauses. Not sure if all of them do though.
... adding _val_:"func(foo)" didn't really run any risk of doing
somethign people didn't expect (unless they have a field named_val_) ...
but people who are use to QUeryParser protecting them from foolish users
that type in leading wildcards would be in for a nasty suprise if we
change the default.
-Hoss
On 4/19/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> from a stability standpoint, i would suggest that people should have to go
> out of their way to get this behavior, since it does open up the
> possiblity of a query OOMing Solr extremely easily.
ConstantScorePrefixQuery is used... there shou
On 4/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: > Any reason that parser.setAllowLeadingWildcards(true) shouldn't be
: > the default?
i'm of two minds on this, both of which vote "don't do it"
from a predictibility standpoint, i think we should keep the default
beahvior the same as th
: > Any reason that parser.setAllowLeadingWildcards(true) shouldn't be
: > the default?
i'm of two minds on this, both of which vote "don't do it"
from a predictibility standpoint, i think we should keep the default
beahvior the same as the base QueryParsers default behavior as much as
possible
On Apr 19, 2007, at 11:37 AM, Michael Kimsal wrote:
It's not that I don't *want* to contribute, but hardly have enough
time to
get the basics
done some days.
You can rest assured that all of us here are in that same boat. :)
And you can also rest assured that the switch your asking for wil
I'm in the middle of looking in to that. For *you* ;) it may seem like a
quick
thing to do. For me, who's not an expert at this stuff, it's a balance
between delving in
deeply enough to figure how to do it and hitting our deadlines.
It's actually on someone else's plate here, but he's backed u
On Apr 19, 2007, at 11:04 AM, Michael Kimsal wrote:
Perhaps I'm simplifying it a bit. It would certainly help out our
comfort
level
to have it either be on or configurable by default, rather than
having to
maintain a
'patched' version (yes, the patch is only one line, but it's the
princi
It still seems like it's only something that would be invoked by a user's
query.
If I queried for *foobar and leading wildcards were not on in the server,
I'd get back nothing, which isn't really correct. I'd think the application
should
tell the user that that syntax
On Apr 19, 2007, at 10:39 AM, Yonik Seeley wrote:
On 4/19/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
parser.setAllowLeadingWildcards(true);
I have also run into this issue and have intended to fix up Solr to
allow configuring that switch on QueryParser.
Any reason that parser.setAllowLeadi
On 4/19/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
parser.setAllowLeadingWildcards(true);
I have also run into this issue and have intended to fix up Solr to
allow configuring that switch on QueryParser.
Any reason that parser.setAllowLeadingWildcards(true) shouldn't be the default?
Does it
#x27;ll eventually get to
this, but someone supply a patch with a test case would get it done
sooner.
I must, however, caveat discussion of leading wildcards with the
underlying effect you get. If you use standard analysis and perform
a leading wildcard query, you incur a (possibly) dramatic hit in
issue and have intended to fix up Solr to
allow configuring that switch on QueryParser. I'll eventually get to
this, but someone supply a patch with a test case would get it done
sooner.
I must, however, caveat discussion of leading wildcards with the
underlying effect you get. If yo
because it's something that we need
(to be able to emulate the previous foo LIKE '%bar%' SQL behaviour we're
replacing), but can't offer our users yet.
On 4/19/07, Burkamp, Christian <[EMAIL PROTECTED]> wrote:
Hi there,
Solr does not support leading wildcards, be
Hi there,
Solr does not support leading wildcards, because it uses Lucene's standard
QueryParser class without changing the defaults. You can easily change this by
inserting the line
parser.setAllowLeadingWildcards(true);
in QueryParsing.java line 92. (This is after creating a QueryP
hi,
we have been trying to get the leading wildcards to work.
we have been looking around the Solr website, the Lucene website, wiki's
and the mailing lists etc ...
but we found a lot of contradictory information.
so we have a few question :
- is the latest version of lucene capab
38 matches
Mail list logo
