You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Matthew King <ma...@gnik.com> on 2003/01/29 18:52:33 UTC
literal operator?
I just ran into a little problem while trying to query for a document
looking for a term that had been indexed using a Keyword field...
My application is using the StandardAnalyzer and the QueryParser to
search the index, so my query looked something like this:
kw:FOOBAR
not surprisingly (now that I know what's going on) I wasn't getting any
hits from this search (because the QueryParser was normalizing the
query term be "foobar" when it had been indexed as "FOOBAR")
I know that i could create my own query to search for "FOOBAR", but it
seems reasonable to add a LITERAL operator so that keywords can be
searched using the QueryParser, no?
Here's the diff for my stab at implementing it:
diff -r1.25 QueryParser.jj
319c319
< "[", "]", "\"", "{", "}", "~", "*", "?" ] >
---
> "[", "]", "\"", "{", "}", "~", "*", "?",
"'" ] >
321c321
< "[", "]", "\"", "{", "}", "~", "*", "?" ]
---
> "[", "]", "\"", "{", "}", "~", "*", "?",
"'" ]
350a351
> | <LITERAL: "'" (~["'"])+ "'">
527a529,533
> }
> | term=<LITERAL>
> [ <CARAT> boost=<NUMBER> ]
> {
> q = new TermQuery(new Term(field, term.image.substring(1,
term.image.length()-1)));
I'm not so sure I like using the single quote here, but it was
available...
What do people think? Is this useful to others?
- matt
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Terry Steichen <te...@net-frame.com>.
Otis, Matt -
I think the idea of adding the capability to do a literal search is
excellent. However, I don't know enough of the parser details to comment on
Matt's specific suggested implementation. I would suggest that, before you
implemented such an enhancement, you publish to the list precisely what the
user-level syntax would be. Then we'd be in a better position to comment on
whether or not it would be confusing.
Regards,
Terry
----- Original Message -----
From: "Otis Gospodnetic" <ot...@yahoo.com>
To: "Lucene Developers List" <lu...@jakarta.apache.org>
Cc: "Matthew King" <ma...@gnik.com>
Sent: Sunday, February 23, 2003 2:35 AM
Subject: Re: literal operator?
> Hello Matthew,
>
> Nobody responded to this one.
> Any strong opinions about including this from developers?
> I thought this would be a useful thing, at first, but it may confuse
> people (users, not developers) more if they search for 'some phrase
> with stop words'. Actually, the diff uses TermQuery, not QueryParser's
> getFieldQuery method, so it wouldn't really work for phrases.
> Matthew, how come you didn't use getFieldQuery, like it is done for
> PhraseQuery, for instance? That would allow you to support searching
> for literal keywords/terms and phrases, I believe.
>
> Does anyone think that including this would be a good idea?
>
> Thanks,
> Otis
>
>
> --- Matthew King <ma...@gnik.com> wrote:
> > I just ran into a little problem while trying to query for a document
> >
> > looking for a term that had been indexed using a Keyword field...
> >
> > My application is using the StandardAnalyzer and the QueryParser to
> > search the index, so my query looked something like this:
> >
> > kw:FOOBAR
> >
> > not surprisingly (now that I know what's going on) I wasn't getting
> > any
> > hits from this search (because the QueryParser was normalizing the
> > query term be "foobar" when it had been indexed as "FOOBAR")
> >
> > I know that i could create my own query to search for "FOOBAR", but
> > it
> > seems reasonable to add a LITERAL operator so that keywords can be
> > searched using the QueryParser, no?
> >
> > Here's the diff for my stab at implementing it:
> >
> > diff -r1.25 QueryParser.jj
> > 319c319
> > < "[", "]", "\"", "{", "}", "~", "*", "?" ]
> > >
> > ---
> > > "[", "]", "\"", "{", "}", "~", "*", "?",
> >
> > "'" ] >
> > 321c321
> > < "[", "]", "\"", "{", "}", "~", "*", "?"
> > ]
> > ---
> > > "[", "]", "\"", "{", "}", "~", "*",
> > "?",
> > "'" ]
> > 350a351
> > > | <LITERAL: "'" (~["'"])+ "'">
> > 527a529,533
> > > }
> > > | term=<LITERAL>
> > > [ <CARAT> boost=<NUMBER> ]
> > > {
> > > q = new TermQuery(new Term(field, term.image.substring(1,
> >
> > term.image.length()-1)));
> >
> > I'm not so sure I like using the single quote here, but it was
> > available...
> >
> > What do people think? Is this useful to others?
> >
> > - matt
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Terry Steichen <te...@net-frame.com>.
After viewing the ensuing clarifications on this, I would like to withdraw
my earlier support, at least for the moment. My reasons are (a) the fact
that this would only apply to the Keyword field, and (b) the use of the
single quote as the trigger. Both of these lead me to the new view that
this would not only be limited in its added value, but would indeed likely
be confusing.
Regards,
Terry
----- Original Message -----
From: "Tatu Saloranta" <ta...@hypermall.net>
To: "Lucene Developers List" <lu...@jakarta.apache.org>
Sent: Sunday, February 23, 2003 2:12 PM
Subject: Re: literal operator?
> On Sunday 23 February 2003 08:56, Matthew King wrote:
> > I'd thought this went into the black hole of feature requests never to
> > return. ;)
> >
> > I also agree that the single quote is probably a bad choice for an
> > operator. In my code i'm actually using "#lit(<term>)" to make things
> > as unambiguous as possible. (but this doesn't really follow the style
> > of other Lucene query syntax operators)
>
> I too think that while for programmers single quote might be ok (it's
> consistent with behaviour of many unix shells), end users would probably
> expect single and double quotes to either work the same, or single
> quote to be taken as literal (to be able to search "foobar's", in
> non-tokenized field?).
>
> One alternative would be using some other non-alphanum character either as
> prefix or suffix. First thing I can think of is using '=' suffix for exact
> match, so something like:
>
> =foobar's
> ="longer non-tokenizer phrase"
>
> and then either
> field=value
> or
> =field:value
> or
> field:=value
>
> depending on what makes most sense for users (most intuitive), or that's
> easiest to implement.
>
> This is of course assuming = isn't already used for something else? (I
don't
> think it is but perhaps I missed something).
>
> >
> > And the reason I didn't use getFieldQuery is because it is using the
> > analyzer to tokenize and would cause me to loose the raw terms, no?
> > Maybe i'm not understanding the code here?
> >
> > One thing to keep in mind is that literal queries will only work with
> > Keyword fields. Literal searches will not work on fields that have
> > been stemmed at indexing time. Perhaps the query parser could be made
> > smart enough to do what the user wants here without them having to ask?
> > Do we know at query time what options a particular field was indexed
> > with?
>
> If that can be determined, it'd be good to do that... it makes no sense to
use
> analyzer when searching field that's not tokenized.
>
> But even if that can not be determined, it should be easy to implement
this
> feature on derived class, for individual apps. App knows which fields are
not
> tokenized, and can override getFieldQuery() to handle these fields
different
> from default implementation.
>
> As usual, it would be nice to have some documentation that explains how to
do
> it. Perhaps FAQ is not the right place... it would be nice to have "best
> practices" page that would contain hints, ideas and suggestions of how
things
> can be customized, how default functionality can be overridden, and
when/why
> it's usually done.
>
> -+ Tatu +-
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Tatu Saloranta <ta...@hypermall.net>.
On Sunday 23 February 2003 08:56, Matthew King wrote:
> I'd thought this went into the black hole of feature requests never to
> return. ;)
>
> I also agree that the single quote is probably a bad choice for an
> operator. In my code i'm actually using "#lit(<term>)" to make things
> as unambiguous as possible. (but this doesn't really follow the style
> of other Lucene query syntax operators)
I too think that while for programmers single quote might be ok (it's
consistent with behaviour of many unix shells), end users would probably
expect single and double quotes to either work the same, or single
quote to be taken as literal (to be able to search "foobar's", in
non-tokenized field?).
One alternative would be using some other non-alphanum character either as
prefix or suffix. First thing I can think of is using '=' suffix for exact
match, so something like:
=foobar's
="longer non-tokenizer phrase"
and then either
field=value
or
=field:value
or
field:=value
depending on what makes most sense for users (most intuitive), or that's
easiest to implement.
This is of course assuming = isn't already used for something else? (I don't
think it is but perhaps I missed something).
>
> And the reason I didn't use getFieldQuery is because it is using the
> analyzer to tokenize and would cause me to loose the raw terms, no?
> Maybe i'm not understanding the code here?
>
> One thing to keep in mind is that literal queries will only work with
> Keyword fields. Literal searches will not work on fields that have
> been stemmed at indexing time. Perhaps the query parser could be made
> smart enough to do what the user wants here without them having to ask?
> Do we know at query time what options a particular field was indexed
> with?
If that can be determined, it'd be good to do that... it makes no sense to use
analyzer when searching field that's not tokenized.
But even if that can not be determined, it should be easy to implement this
feature on derived class, for individual apps. App knows which fields are not
tokenized, and can override getFieldQuery() to handle these fields different
from default implementation.
As usual, it would be nice to have some documentation that explains how to do
it. Perhaps FAQ is not the right place... it would be nice to have "best
practices" page that would contain hints, ideas and suggestions of how things
can be customized, how default functionality can be overridden, and when/why
it's usually done.
-+ Tatu +-
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hello,
> I'd thought this went into the black hole of feature requests never
> to return. ;)
No, just my Lucene mail folder.
> I also agree that the single quote is probably a bad choice for an
> operator. In my code i'm actually using "#lit(<term>)" to make
> things as unambiguous as possible. (but this doesn't really follow
the
> style of other Lucene query syntax operators)
> And the reason I didn't use getFieldQuery is because it is using the
> analyzer to tokenize and would cause me to loose the raw terms, no?
> Maybe i'm not understanding the code here?
No, you are right, I didn't see the Analyzer in getFieldQuery last
night.
> One thing to keep in mind is that literal queries will only work with
>
> Keyword fields. Literal searches will not work on fields that have
> been stemmed at indexing time. Perhaps the query parser could be
> made
> smart enough to do what the user wants here without them having to
> ask?
> Do we know at query time what options a particular field was
> indexed
> with?
That is what I was trying to say last night - this won't work with
fields other than Keyword, and if people don't get results they expect
when they search on non-Keyword fields, they'll think it's a bug.
I do not think we can determine if the field being searched is of type
Keyword or not at the search time. If I'm wrong, somebody correct me,
please.
Because of the above I'm hesitant to include your patch. Let's see
what others think.
Otis
> - matt
>
> On Sunday, February 23, 2003, at 02:35 AM, Otis Gospodnetic wrote:
>
> > Hello Matthew,
> >
> > Nobody responded to this one.
> > Any strong opinions about including this from developers?
> > I thought this would be a useful thing, at first, but it may
> confuse
> > people (users, not developers) more if they search for 'some phrase
> > with stop words'. Actually, the diff uses TermQuery, not
> QueryParser's
> > getFieldQuery method, so it wouldn't really work for phrases.
> > Matthew, how come you didn't use getFieldQuery, like it is done for
> > PhraseQuery, for instance? That would allow you to support
> searching
> > for literal keywords/terms and phrases, I believe.
> >
> > Does anyone think that including this would be a good idea?
> >
> > Thanks,
> > Otis
> >
> >
> > --- Matthew King <ma...@gnik.com> wrote:
> >> I just ran into a little problem while trying to query for a
> document
> >>
> >> looking for a term that had been indexed using a Keyword field...
> >>
> >> My application is using the StandardAnalyzer and the QueryParser
> to
> >> search the index, so my query looked something like this:
> >>
> >> kw:FOOBAR
> >>
> >> not surprisingly (now that I know what's going on) I wasn't
> getting
> >> any
> >> hits from this search (because the QueryParser was normalizing the
> >> query term be "foobar" when it had been indexed as "FOOBAR")
> >>
> >> I know that i could create my own query to search for "FOOBAR",
> but
> >> it
> >> seems reasonable to add a LITERAL operator so that keywords can be
> >> searched using the QueryParser, no?
> >>
> >> Here's the diff for my stab at implementing it:
> >>
> >> diff -r1.25 QueryParser.jj
> >> 319c319
> >> < "[", "]", "\"", "{", "}", "~", "*",
> "?" ]
> >>>
> >> ---
> >>> "[", "]", "\"", "{", "}", "~", "*",
> "?",
> >>
> >> "'" ] >
> >> 321c321
> >> < "[", "]", "\"", "{", "}", "~", "*",
> "?"
> >> ]
> >> ---
> >>> "[", "]", "\"", "{", "}", "~", "*",
> >> "?",
> >> "'" ]
> >> 350a351
> >>> | <LITERAL: "'" (~["'"])+ "'">
> >> 527a529,533
> >>> }
> >>> | term=<LITERAL>
> >>> [ <CARAT> boost=<NUMBER> ]
> >>> {
> >>> q = new TermQuery(new Term(field,
> term.image.substring(1,
> >>
> >> term.image.length()-1)));
> >>
> >> I'm not so sure I like using the single quote here, but it was
> >> available...
> >>
> >> What do people think? Is this useful to others?
> >>
> >> - matt
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> lucene-dev-help@jakarta.apache.org
> >>
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Matthew King <ma...@gnik.com>.
I'd thought this went into the black hole of feature requests never to
return. ;)
I also agree that the single quote is probably a bad choice for an
operator. In my code i'm actually using "#lit(<term>)" to make things
as unambiguous as possible. (but this doesn't really follow the style
of other Lucene query syntax operators)
And the reason I didn't use getFieldQuery is because it is using the
analyzer to tokenize and would cause me to loose the raw terms, no?
Maybe i'm not understanding the code here?
One thing to keep in mind is that literal queries will only work with
Keyword fields. Literal searches will not work on fields that have
been stemmed at indexing time. Perhaps the query parser could be made
smart enough to do what the user wants here without them having to ask?
Do we know at query time what options a particular field was indexed
with?
- matt
On Sunday, February 23, 2003, at 02:35 AM, Otis Gospodnetic wrote:
> Hello Matthew,
>
> Nobody responded to this one.
> Any strong opinions about including this from developers?
> I thought this would be a useful thing, at first, but it may confuse
> people (users, not developers) more if they search for 'some phrase
> with stop words'. Actually, the diff uses TermQuery, not QueryParser's
> getFieldQuery method, so it wouldn't really work for phrases.
> Matthew, how come you didn't use getFieldQuery, like it is done for
> PhraseQuery, for instance? That would allow you to support searching
> for literal keywords/terms and phrases, I believe.
>
> Does anyone think that including this would be a good idea?
>
> Thanks,
> Otis
>
>
> --- Matthew King <ma...@gnik.com> wrote:
>> I just ran into a little problem while trying to query for a document
>>
>> looking for a term that had been indexed using a Keyword field...
>>
>> My application is using the StandardAnalyzer and the QueryParser to
>> search the index, so my query looked something like this:
>>
>> kw:FOOBAR
>>
>> not surprisingly (now that I know what's going on) I wasn't getting
>> any
>> hits from this search (because the QueryParser was normalizing the
>> query term be "foobar" when it had been indexed as "FOOBAR")
>>
>> I know that i could create my own query to search for "FOOBAR", but
>> it
>> seems reasonable to add a LITERAL operator so that keywords can be
>> searched using the QueryParser, no?
>>
>> Here's the diff for my stab at implementing it:
>>
>> diff -r1.25 QueryParser.jj
>> 319c319
>> < "[", "]", "\"", "{", "}", "~", "*", "?" ]
>>>
>> ---
>>> "[", "]", "\"", "{", "}", "~", "*", "?",
>>
>> "'" ] >
>> 321c321
>> < "[", "]", "\"", "{", "}", "~", "*", "?"
>> ]
>> ---
>>> "[", "]", "\"", "{", "}", "~", "*",
>> "?",
>> "'" ]
>> 350a351
>>> | <LITERAL: "'" (~["'"])+ "'">
>> 527a529,533
>>> }
>>> | term=<LITERAL>
>>> [ <CARAT> boost=<NUMBER> ]
>>> {
>>> q = new TermQuery(new Term(field, term.image.substring(1,
>>
>> term.image.length()-1)));
>>
>> I'm not so sure I like using the single quote here, but it was
>> available...
>>
>> What do people think? Is this useful to others?
>>
>> - matt
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>>
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
+1 on the concept of a literal term query. Syntax I'm not particular
about, but single quotes seem fine to me.
On Sunday, February 23, 2003, at 01:35 AM, Otis Gospodnetic wrote:
> Hello Matthew,
>
> Nobody responded to this one.
> Any strong opinions about including this from developers?
> I thought this would be a useful thing, at first, but it may confuse
> people (users, not developers) more if they search for 'some phrase
> with stop words'. Actually, the diff uses TermQuery, not QueryParser's
> getFieldQuery method, so it wouldn't really work for phrases.
> Matthew, how come you didn't use getFieldQuery, like it is done for
> PhraseQuery, for instance? That would allow you to support searching
> for literal keywords/terms and phrases, I believe.
>
> Does anyone think that including this would be a good idea?
>
> Thanks,
> Otis
>
>
> --- Matthew King <ma...@gnik.com> wrote:
>> I just ran into a little problem while trying to query for a document
>>
>> looking for a term that had been indexed using a Keyword field...
>>
>> My application is using the StandardAnalyzer and the QueryParser to
>> search the index, so my query looked something like this:
>>
>> kw:FOOBAR
>>
>> not surprisingly (now that I know what's going on) I wasn't getting
>> any
>> hits from this search (because the QueryParser was normalizing the
>> query term be "foobar" when it had been indexed as "FOOBAR")
>>
>> I know that i could create my own query to search for "FOOBAR", but
>> it
>> seems reasonable to add a LITERAL operator so that keywords can be
>> searched using the QueryParser, no?
>>
>> Here's the diff for my stab at implementing it:
>>
>> diff -r1.25 QueryParser.jj
>> 319c319
>> < "[", "]", "\"", "{", "}", "~", "*", "?" ]
>>>
>> ---
>>> "[", "]", "\"", "{", "}", "~", "*", "?",
>>
>> "'" ] >
>> 321c321
>> < "[", "]", "\"", "{", "}", "~", "*", "?"
>> ]
>> ---
>>> "[", "]", "\"", "{", "}", "~", "*",
>> "?",
>> "'" ]
>> 350a351
>>> | <LITERAL: "'" (~["'"])+ "'">
>> 527a529,533
>>> }
>>> | term=<LITERAL>
>>> [ <CARAT> boost=<NUMBER> ]
>>> {
>>> q = new TermQuery(new Term(field, term.image.substring(1,
>>
>> term.image.length()-1)));
>>
>> I'm not so sure I like using the single quote here, but it was
>> available...
>>
>> What do people think? Is this useful to others?
>>
>> - matt
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>>
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: literal operator?
Posted by Otis Gospodnetic <ot...@yahoo.com>.
Hello Matthew,
Nobody responded to this one.
Any strong opinions about including this from developers?
I thought this would be a useful thing, at first, but it may confuse
people (users, not developers) more if they search for 'some phrase
with stop words'. Actually, the diff uses TermQuery, not QueryParser's
getFieldQuery method, so it wouldn't really work for phrases.
Matthew, how come you didn't use getFieldQuery, like it is done for
PhraseQuery, for instance? That would allow you to support searching
for literal keywords/terms and phrases, I believe.
Does anyone think that including this would be a good idea?
Thanks,
Otis
--- Matthew King <ma...@gnik.com> wrote:
> I just ran into a little problem while trying to query for a document
>
> looking for a term that had been indexed using a Keyword field...
>
> My application is using the StandardAnalyzer and the QueryParser to
> search the index, so my query looked something like this:
>
> kw:FOOBAR
>
> not surprisingly (now that I know what's going on) I wasn't getting
> any
> hits from this search (because the QueryParser was normalizing the
> query term be "foobar" when it had been indexed as "FOOBAR")
>
> I know that i could create my own query to search for "FOOBAR", but
> it
> seems reasonable to add a LITERAL operator so that keywords can be
> searched using the QueryParser, no?
>
> Here's the diff for my stab at implementing it:
>
> diff -r1.25 QueryParser.jj
> 319c319
> < "[", "]", "\"", "{", "}", "~", "*", "?" ]
> >
> ---
> > "[", "]", "\"", "{", "}", "~", "*", "?",
>
> "'" ] >
> 321c321
> < "[", "]", "\"", "{", "}", "~", "*", "?"
> ]
> ---
> > "[", "]", "\"", "{", "}", "~", "*",
> "?",
> "'" ]
> 350a351
> > | <LITERAL: "'" (~["'"])+ "'">
> 527a529,533
> > }
> > | term=<LITERAL>
> > [ <CARAT> boost=<NUMBER> ]
> > {
> > q = new TermQuery(new Term(field, term.image.substring(1,
>
> term.image.length()-1)));
>
> I'm not so sure I like using the single quote here, but it was
> available...
>
> What do people think? Is this useful to others?
>
> - matt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org