Return-Path: 
 <java-dev-return-47617-apmail-lucene-java-dev-archive=lucene.apache.org@lucene.apache.org>
Delivered-To: apmail-lucene-java-dev-archive@www.apache.org
Received: (qmail 86361 invoked from network); 12 Mar 2010 19:00:23 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 12 Mar 2010 19:00:23 -0000
Received: (qmail 82740 invoked by uid 500); 12 Mar 2010 18:59:45 -0000
Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org
Received: (qmail 82699 invoked by uid 500); 12 Mar 2010 18:59:45 -0000
Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:java-dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:java-dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:java-dev@lucene.apache.org>
List-Id: <java-dev.lucene.apache.org>
Reply-To: java-dev@lucene.apache.org
Delivered-To: mailing list java-dev@lucene.apache.org
Received: (qmail 82691 invoked by uid 99); 12 Mar 2010 18:59:45 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 18:59:45 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of erickerickson@gmail.com
 designates 74.125.82.176 as permitted sender)
Received: from [74.125.82.176] (HELO mail-wy0-f176.google.com) (74.125.82.176)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 18:59:37 +0000
Received: by wyf19 with SMTP id 19so272645wyf.35
        for <java-dev@lucene.apache.org>;
 Fri, 12 Mar 2010 10:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=HOgMYAhDOd6jhNSdhMLn/zJsqjXiF0HwleDS8REWMCE=;
        b=EslbH2poFxrCmg/IqmGPrm0yWcpqOV4FeccK5J6FKGq9ogty4Mb4LOUyIdod5amTsC
         mO4jsBJ8tskz8/Z0+kymgTYoutTgQEUVrUMTPvyQZanZuGyKpN2siPyY8gmPI7Um0WLr
         OYU15w0eaxM23kUE11zzEZqkssPkKdO62+yko=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=g4Mz6e41UD2BqWIAscx8tyD9dRvyNbntoU0ST/D1ceDFFzQ93Q5lbVqG3vyA2eLqK9
         hHABhKL5aLXWfgpwSUo1eO6vyeJWwuOEZi3PJbq6IIsOoAaX4z5Zwaio4dWQHqIyPlFZ
         rBvaDFoT0fHz4fV9IjQn4sGY6FoydGeiX4X6M=
MIME-Version: 1.0
Received: by 10.216.171.207 with SMTP id r57mr436581wel.146.1268420357332;
	Fri, 12 Mar 2010 10:59:17 -0800 (PST)
In-Reply-To: <105959204.230971268416587474.JavaMail.jira@brutus.apache.org>
References: <516615439.186211268253027222.JavaMail.jira@brutus.apache.org>
	 <105959204.230971268416587474.JavaMail.jira@brutus.apache.org>
Date: Fri, 12 Mar 2010 13:59:17 -0500
Message-ID: <359a92831003121059w3fc1daf0p428547957e605cb7@mail.gmail.com>
Subject: Re: [jira] Commented: (LUCENE-2308) Separately specify a field's type
From: Erick Erickson <erickerickson@gmail.com>
To: java-dev@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016367fa8f5d3d7c704819f2028
X-Virus-Checked: Checked by ClamAV on apache.org

--0016367fa8f5d3d7c704819f2028
Content-Type: text/plain; charset=ISO-8859-1

Congrats Chris!

I vote for thinkAboutNotIncludingNormsMaybe(true|false) <G>.....

Seriously double negatives are ugly IMO, +1 for changing....

Erick

On Fri, Mar 12, 2010 at 12:56 PM, Chris Male (JIRA) <jira@apache.org> wrote:

>
>    [
> https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844587#action_12844587]
>
> Chris Male commented on LUCENE-2308:
> ------------------------------------
>
> I agree entirely.  This is definitely the moment to remove any ambiguity or
> confusion in this API.  I'll make sure to incorporate this idea.
>
> > Separately specify a field's type
> > ---------------------------------
> >
> >                 Key: LUCENE-2308
> >                 URL: https://issues.apache.org/jira/browse/LUCENE-2308
> >             Project: Lucene - Java
> >          Issue Type: Improvement
> >          Components: Index
> >            Reporter: Michael McCandless
> >
> > This came up from dicussions on IRC.  I'm summarizing here...
> > Today when you make a Field to add to a document you can set things
> > index or not, stored or not, analyzed or not, details like omitTfAP,
> > omitNorms, index term vectors (separately controlling
> > offsets/positions), etc.
> > I think we should factor these out into a new class (FieldType?).
> > Then you could re-use this FieldType instance across multiple fields.
> > The Field instance would still hold the actual value.
> > We could then do per-field analyzers by adding a setAnalyzer on the
> > FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise
> > for per-field codecs (with flex), where we now have
> > PerFieldCodecWrapper).
> > This would NOT be a schema!  It's just refactoring what we already
> > specify today.  EG it's not serialized into the index.
> > This has been discussed before, and I know Michael Busch opened a more
> > ambitious (I think?) issue.  I think this is a good first baby step.  We
> could
> > consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe hold
> > off on that for starters...
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

--0016367fa8f5d3d7c704819f2028
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Congrats Chris!<div><br></div><div>I vote for thinkAboutNotIncludingNormsMa=
ybe(true|false) &lt;G&gt;.....</div><div><br></div><div>Seriously double ne=
gatives are ugly IMO, +1 for changing....</div><div><br></div><div>Erick<br=
>
<br><div class=3D"gmail_quote">On Fri, Mar 12, 2010 at 12:56 PM, Chris Male=
 (JIRA) <span dir=3D"ltr">&lt;<a href=3D"mailto:jira@apache.org">jira@apach=
e.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
 =A0 =A0[ <a href=3D"https://issues.apache.org/jira/browse/LUCENE-2308?page=
=3Dcom.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&amp;foc=
usedCommentId=3D12844587#action_12844587" target=3D"_blank">https://issues.=
apache.org/jira/browse/LUCENE-2308?page=3Dcom.atlassian.jira.plugin.system.=
issuetabpanels:comment-tabpanel&amp;focusedCommentId=3D12844587#action_1284=
4587</a> ]<br>

<div class=3D"im"><br>
Chris Male commented on LUCENE-2308:<br>
------------------------------------<br>
<br>
</div>I agree entirely. =A0This is definitely the moment to remove any ambi=
guity or confusion in this API. =A0I&#39;ll make sure to incorporate this i=
dea.<br>
<div><div></div><div class=3D"h5"><br>
&gt; Separately specify a field&#39;s type<br>
&gt; ---------------------------------<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: LUCENE-2308<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: <a href=3D"https://issues.apache.=
org/jira/browse/LUCENE-2308" target=3D"_blank">https://issues.apache.org/ji=
ra/browse/LUCENE-2308</a><br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 Project: Lucene - Java<br>
&gt; =A0 =A0 =A0 =A0 =A0Issue Type: Improvement<br>
&gt; =A0 =A0 =A0 =A0 =A0Components: Index<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0Reporter: Michael McCandless<br>
&gt;<br>
&gt; This came up from dicussions on IRC. =A0I&#39;m summarizing here...<br=
>
&gt; Today when you make a Field to add to a document you can set things<br=
>
&gt; index or not, stored or not, analyzed or not, details like omitTfAP,<b=
r>
&gt; omitNorms, index term vectors (separately controlling<br>
&gt; offsets/positions), etc.<br>
&gt; I think we should factor these out into a new class (FieldType?).<br>
&gt; Then you could re-use this FieldType instance across multiple fields.<=
br>
&gt; The Field instance would still hold the actual value.<br>
&gt; We could then do per-field analyzers by adding a setAnalyzer on the<br=
>
&gt; FieldType, instead of the separate PerFieldAnalzyerWrapper (likewise<b=
r>
&gt; for per-field codecs (with flex), where we now have<br>
&gt; PerFieldCodecWrapper).<br>
&gt; This would NOT be a schema! =A0It&#39;s just refactoring what we alrea=
dy<br>
&gt; specify today. =A0EG it&#39;s not serialized into the index.<br>
&gt; This has been discussed before, and I know Michael Busch opened a more=
<br>
&gt; ambitious (I think?) issue. =A0I think this is a good first baby step.=
 =A0We could<br>
&gt; consider a hierarchy of FIeldType (NumericFieldType, etc.) but maybe h=
old<br>
&gt; off on that for starters...<br>
<br>
--<br>
This message is automatically generated by JIRA.<br>
-<br>
You can reply to this email to add a comment to the issue online.<br>
<br>
<br>
---------------------------------------------------------------------<br>
To unsubscribe, e-mail: <a href=3D"mailto:java-dev-unsubscribe@lucene.apach=
e.org">java-dev-unsubscribe@lucene.apache.org</a><br>
For additional commands, e-mail: <a href=3D"mailto:java-dev-help@lucene.apa=
che.org">java-dev-help@lucene.apache.org</a><br>
<br>
</div></div></blockquote></div><br></div>

--0016367fa8f5d3d7c704819f2028--