You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Anthony Urso <an...@gmail.com> on 2008/09/12 03:47:22 UTC
Re: Case Sensitivity
On Thu, Aug 28, 2008 at 11:16 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
>
> Yonik Seeley wrote:
>>
>> I wasn't originally going to add a Field.Index at all for omitNorms,
>> but Doug suggested it.
>> The problem with this type-safe way of doing things is the
>> combinatorial explosion.
>
> Yeah I realize that. Now that we have omitTF as an option we could really
> go crazy ;)
>
> I figured since we already have NOT_ANALYZED_NO_NORMS we may as well round
> it out with ANALYZED_NO_NORMS, and then stop there. Plus, people have been
> surprised that you could do ANALYZED_NO_NORMS, yet it is useful.
Why not make this flag field into a bitmap?
Cheers,
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Case Sensitivity
Posted by Andrzej Bialecki <ab...@getopt.org>.
Michael McCandless wrote:
>
> Anthony Urso wrote:
>
>> On Thu, Aug 28, 2008 at 11:16 AM, Michael McCandless
>> <lu...@mikemccandless.com> wrote:
>>>
>>> Yonik Seeley wrote:
>>>>
>>>> I wasn't originally going to add a Field.Index at all for omitNorms,
>>>> but Doug suggested it.
>>>> The problem with this type-safe way of doing things is the
>>>> combinatorial explosion.
>>>
>>> Yeah I realize that. Now that we have omitTF as an option we could
>>> really
>>> go crazy ;)
>>>
>>> I figured since we already have NOT_ANALYZED_NO_NORMS we may as well
>>> round
>>> it out with ANALYZED_NO_NORMS, and then stop there. Plus, people
>>> have been
>>> surprised that you could do ANALYZED_NO_NORMS, yet it is useful.
>>
>> Why not make this flag field into a bitmap?
>
> I think that makes sense, at some point in the future (when we clean up
> Fieldable/AbstractField/Field?). This way you can OR together things
> like NORMS/NO_NORMS, ANALYZED/NOT_ANALYZED, INCLUDE_TF/OMIT_TF, etc.
+1 on that. AFAIR the original motivation for these type-safe
enumerations was that some combination of flags are invalid /
unsupported, and then you would discover it only at runtime. But the
problems with this approach seem to outweigh the benefits ...
Perhaps we could provide static methods on Fieldable that test the
validity of flag combinations with particular version of Lucene?
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Case Sensitivity
Posted by Michael McCandless <lu...@mikemccandless.com>.
Anthony Urso wrote:
> On Thu, Aug 28, 2008 at 11:16 AM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> Yonik Seeley wrote:
>>>
>>> I wasn't originally going to add a Field.Index at all for omitNorms,
>>> but Doug suggested it.
>>> The problem with this type-safe way of doing things is the
>>> combinatorial explosion.
>>
>> Yeah I realize that. Now that we have omitTF as an option we could
>> really
>> go crazy ;)
>>
>> I figured since we already have NOT_ANALYZED_NO_NORMS we may as
>> well round
>> it out with ANALYZED_NO_NORMS, and then stop there. Plus, people
>> have been
>> surprised that you could do ANALYZED_NO_NORMS, yet it is useful.
>
> Why not make this flag field into a bitmap?
I think that makes sense, at some point in the future (when we clean
up Fieldable/AbstractField/Field?). This way you can OR together
things like NORMS/NO_NORMS, ANALYZED/NOT_ANALYZED, INCLUDE_TF/OMIT_TF,
etc.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org