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
, 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 wildcards in
config files.
How I can
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 wildcards in
config files
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? Thank you
:
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
[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 in
config files.
How I can enable
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,
- 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 leading
- 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 like
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 build, dude:
[EMAIL
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
field name=estimatedRepairs type=sfloat indexed=true stored=true
multiValued=true/
I execute a query with the below
[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 nonfield:test
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 we use wildcards
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
@lucene.apache.org
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(true
Burkamp, Christian [EMAIL PROTECTED]
19/04/2007 12:37
Please respond to
solr-user@lucene.apache.org
To
solr-user@lucene.apache.org
cc
Subject
AW: Leading wildcards
Hi there,
Solr does not support leading wildcards, because it uses Lucene's standard
QueryParser class without changing
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 capable
(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, because it uses Lucene's standard
QueryParser class without changing
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 you use standard analysis and perform
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
terms of performance. Lucene has to scan *every* term
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
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
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 isn't supported.
Perhaps
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
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
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
: 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 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
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
: 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.
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:*bar
: 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 exception
32 matches
Mail list logo
