On Fri, Jan 26, 2007, Otis Gospodnetic wrote about "Re: NO_NORMS and
TOKENIZED?":
> Funny, I was looking to do the same thing the other day and gave up thinking
> it wasn't possible, not being aware of setOmitNorms(). Yeah, a javadoc patch
> would be welcome.
>
> Otis
Before I go ahead and post a javadoc patch, I want to question again the
wisdom of this whole situation:
Currently, most of a Field's parameters must be defined during its
construction. There is no method to change whether this Field object is to
be stored, to be compressed, to be indexed, to be tokenized - all these
things MUST be defined during the field's construction. So it is very
strange, and completely unexpected (at least to me and to Otis), that just
the "omitNorms" parameter can be changed after after construction, with a
"setOmitNorms" method - and not only can it be set after construction, in
some cases it must be set after construction, because the constructor doesn't
allow you to set it if you want an analyzer...
So perhaps changing the code, not just the javadoc, would be better?
One way to do it while keeping backward compatibility is to add something
like TOKENIZED_NO_NORMS to Field.Index.
> >...
> > I hadn't added a Field.Index option at all, and Doug suggested
> > NO_NORMS, probably because it's mostly harmless to new users who might
> > disable length normalization without realizing the implications.
If we had also a "TOKENIZED_NO_NORMS", why would new users accidentally
use it? I guess the javadoc of this parameter could also warn against its
use (something like "not recommended for general use", or whatever)?
--
Nadav Har'El | Thursday, Feb 15 2007, 27 Shevat 5767
IBM Haifa Research Lab |-----------------------------------------
|How long a minute depends on what side of
http://nadav.harel.org.il |the bathroom door you're on.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
