lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: [jira] Commented: (LUCENE-2308) Separately specify a field's type
Date Fri, 12 Mar 2010 20:01:27 GMT
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


Mime
View raw message