Return-Path: 
 <lucene-dev-return-3173-qmlist-jakarta-archive-lucene-dev=nagoya.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org
Received: (qmail 25976 invoked from network); 23 Feb 2003 19:51:26 -0000
Received: from exchange.sun.com (192.18.33.10)
  by daedalus.apache.org with SMTP; 23 Feb 2003 19:51:26 -0000
Received: (qmail 8315 invoked by uid 97); 23 Feb 2003 19:53:05 -0000
Delivered-To: qmlist-jakarta-archive-lucene-dev@nagoya.betaversion.org
Received: (qmail 8308 invoked from network); 23 Feb 2003 19:53:05 -0000
Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12)
  by nagoya.betaversion.org with SMTP; 23 Feb 2003 19:53:05 -0000
Received: (qmail 25696 invoked by uid 500); 23 Feb 2003 19:51:23 -0000
Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:lucene-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:lucene-dev-help@jakarta.apache.org>
List-Post: <mailto:lucene-dev@jakarta.apache.org>
List-Id: "Lucene Developers List" <lucene-dev.jakarta.apache.org>
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Delivered-To: mailing list lucene-dev@jakarta.apache.org
Received: (qmail 25683 invoked from network); 23 Feb 2003 19:51:23 -0000
Received: from smtp10.atl.mindspring.net (207.69.200.246)
  by daedalus.apache.org with SMTP; 23 Feb 2003 19:51:23 -0000
Received: from h-66-167-144-252.mclnva23.covad.net ([66.167.144.252]
 helo=Stete03)
	by smtp10.atl.mindspring.net with smtp (Exim 3.33 #1)
	id 18n29m-0003mv-00; Sun, 23 Feb 2003 14:51:26 -0500
Message-ID: <013f01c2db73$7a4a3200$0201a8c0@netframe.com>
From: "Terry Steichen" <terry@net-frame.com>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>,
	<tatu@hypermall.net>
References: <6109CE36-4747-11D7-AB53-00039303E4E2@gnik.com>
 <200302231212.47705.tatu@hypermall.net>
Subject: Re: literal operator?
Date: Sun, 23 Feb 2003 14:40:53 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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" <tatu@hypermall.net>
To: "Lucene Developers List" <lucene-dev@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