[
https://issues.apache.org/jira/browse/LUCENE-3453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186017#comment-13186017
]
Chris Male edited comment on LUCENE-3453 at 1/14/12 12:31 AM:
--------------------------------------------------------------
{quote}
LUCENE-3694: moved all setXXX methods in NumericField and
DocValuesField up into Field.java (as setValue methods)
{quote}
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}
Renamed/generalized BinaryField to StoredField, so that you can
use it to store any value, including numerics. I generalized the
codecs so they mark a stored field as numeric if its
.numericValue() is non-null, and at document load time they now
always create a StoredField instance. This also means you have to
call .numericValue (not .stringValue()) on the returned
StoredField, after indexing a NumericField.
{quote}
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?
{quote}
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.
{quote}
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.
was (Author: cmale):
{quote}
LUCENE-3694: moved all setXXX methods in NumericField and
DocValuesField up into Field.java (as setValue methods)
{quote}
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}
Renamed/generalized BinaryField to StoredField, so that you can
use it to store any value, including numerics. I generalized the
codecs so they mark a stored field as numeric if its
.numericValue() is non-null, and at document load time they now
always create a StoredField instance. This also means you have to
call .numericValue (not .stringValue()) on the returned
StoredField, after indexing a NumericField.
{quote}
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?
{quote}
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.
{quote}
Good idea. Could we make this cleaner by having a 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.
> 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]
