Similarly, if you know that you are dealing with domain names or ip
addresses (or other text with discrete parts), you can reverse the order
of the parts rather than at the character level making it more human
readable: com.example.www Your query would then be sent as com.example.*
-Sean
Ian
the solution that works for me is to store the field in reverse order,
and have your application reverse the field in the query.
so the field www.example.com would be stored as
moc.elmpaxe.www
so now I can do a search for *.example.com in my application.
Regards
Ian
(hat tip to erik for the id
Vote for that issue and perhaps it'll gain some more traction. A former
colleague of mine was the one who contributed the patch in SOLR 218 and it
would be nice to have that configuration option 'standard' (if off by
default) in the next SOLR release.
On Nov 12, 2007 11:18 AM, Traut <[EMAIL PROT
Seems like there is no way to enable leading wildcard queries except
code editing and files repacking. :(
On 11/12/07, Bill Au <[EMAIL PROTECTED]> wrote:
> The related bug is still open:
>
> http://issues.apache.org/jira/browse/SOLR-218
>
> Bill
>
> On Nov 12, 2007 10:25 AM, Traut <[EMAIL PROTECTE
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 nightly Solr build
> and I
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
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 ad
: > 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.
: 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" has meaning by default in the query parser ... it's m
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 isn't supported.
Perhaps I
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
Agreed, but in our tests (100M index) it wasn't a performance hit, and much
better (as in it actually worked) than MSSQL ;)
On 4/19/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
On Apr 19, 2007, at 6:56 AM, Michael Kimsal wrote:
> It's bugged us a little bit, because it's something that we ne
On Apr 19, 2007, at 6:56 AM, Michael Kimsal wrote:
It's bugged us a little bit, 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.
I have also run into this issue and have intended to fix up
I've investigated this recently, and it looks like the latest lucene dev
supposedly supports leading/trailing at the same time. However, I couldn't
get the latest dev solr to build with the latest dev lucene (as of two weeks
ago). A lucene mailing list seemed to indicate that lucene as of the la
27 matches
Mail list logo
