Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of markrmiller@gmail.com
 designates 209.85.218.217 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=N3fyAPZ1oc0idOXQOke/LY18KaU6Gja2PLHuBPljkh+iJ0vVM4AunAoyfkumh8mtXJ
         +qlBQMb11vmLDGoiU5oMIcPxIyXoC6hm5AoHMlIK5jo7J9FK2Ndj3+tr44fFE/g8nG81
         WPASh0fGS2jlM75xDA/aJ9uU6CLrf/2joON2s=
Message-Id: <5850CEE2-DEAC-4E7B-A130-78B333B0BBAB@gmail.com>
From: Mark Miller <markrmiller@gmail.com>
To: "java-dev@lucene.apache.org" <java-dev@lucene.apache.org>
In-Reply-To: <506281434.233531268423007225.JavaMail.jira@brutus.apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 7E18)
Subject: Re: [jira] Commented: (LUCENE-2308) Separately specify a field's type
Date: Fri, 12 Mar 2010 15:01:27 -0500
References: <506281434.233531268423007225.JavaMail.jira@brutus.apache.org>

Committers are competant in different areas of the code.  Even mike  
wasn't big into the search side until per segment.  Commiters are  
trusted to mess with the pieces they know.

I don't see anyone even remotely suggesting that users should have to  
understand all of the implications of posting format modifications.

Just sounds like a nasty jab to me.

- Mark

http://www.lucidimagination.com

On Mar 12, 2010, at 2:43 PM, "Marvin Humphrey (JIRA)"  
<jira@apache.org> wrote:

>
>    [ https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844637#action_12844637 
>  ]
>
> Marvin Humphrey commented on LUCENE-2308:
> -----------------------------------------
>
> If you disable term freq, you also have to disable positions.  The  
> "freq"
> tells you how many positions there are.
>
> I think it's asking an awful lot of our users to require that they  
> understand
> all the implications of posting format modifications when committers
> have difficulty mastering all the subtleties.
>
>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org