LUCENE-3694: moved all setXXX methods in NumericField and DocValuesField up into Field.java (as setValue methods)
I like this idea, but I wonder if it could be a source of confusion. People who are indexing numerical content need to use NumericField or DocValuesField ideally. Having it appear as though they can use Field and get the same indexing behavior as from NumericField could lead to bugs, right?
In fact you can simply use Field directly to index a numeric field or
a doc values field, ie, DocValuesField/NumericField are truly just
sugar now. You can do everything with Field (expert) that you can do
with these sugar classes... or at least I think so
Pretty cool idea I have to say. Somewhere during all these discussion we talked about allowing bytes to be indexed, I guess when/if we ever get to that, we'll need to re-create a BinaryField?
Yeah I think we'd address that if/when we somehow allow indexing of
byte valued fields... even so, expert apps could code directly to
IF/IFT (or even subclass Field possibly) if they have some way to
"index" byte content...
You can still reuse a Field (change its value), however I madte this more strict: you can only change the value to another value of the same type.
Good idea. Could we make this cleaner by having a more general DataType enum? Each constructor with its typed parameter could then set the DataType. In each of the setXXX methods we can just check if the DataType is appropriate, rather than using instanceof/isBinary() etc. This could be internal to Field at the moment but could prove useful down the line.
We could explore that (making Field's fieldData more strongly typed),
instead of dynamically checking types. Field has been dynamically
But I think we can/should do that after committing this first cleanup?
I suspect that could be a major change just by itself...
This would clean up tokenStream creation too – instead of probing
dynamically for string/reader/pre-tokenized we'd switch on the type.