Michael McCandless wrote:
Anthony Urso wrote:
On Thu, Aug 28, 2008 at 11:16 AM, Michael McCandless
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
