[
https://issues.apache.org/jira/browse/LUCENE-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186173#comment-13186173
]
Michael McCandless commented on LUCENE-3453:
--------------------------------------------
{quote}
bq. 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?
{quote}
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 :)
bq. 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...
{quote}
bq. 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.
{quote}
We could explore that (making Field's fieldData more strongly typed),
instead of dynamically checking types. Field has been dynamically
typed forever...
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.
> remove IndexDocValuesField
> --------------------------
>
> Key: LUCENE-3453
> URL: https://issues.apache.org/jira/browse/LUCENE-3453
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-3453.patch, LUCENE-3453.patch
>
>
> Its confusing how we present CSF functionality to the user, its actually not
> a "field" but an "attribute" of a field like STORED or INDEXED.
> Otherwise, its really hard to think about CSF because there is a mismatch
> between the APIs and the index format.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
