[
https://issues.apache.org/jira/browse/LUCENE-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870613#comment-16870613
]
Namgyu Kim commented on LUCENE-8870:
------------------------------------
Thank you for your reply! [~sokolov] :D
I want to make sure that I understand your opinion well.
{quote}in the end we store the value as an Object and then later cast it.
Callers that also handle values generically, as Objects then need an adapter to
detect the type of a value, cast it properly, only to have Lucene throw away
all the type info and do that dance all over again internally!
{quote}
I think this is a structure for providing various constructors to users.
(Reader, CharSequence, BytesRef, ...)
Of course we can only provide it in Object form and handle it in the
constructor.
But isn't it unfriendly to API users?
And I'm not sure about it because the IndexableFieldType check logic is
different depending on the value type.
ex)
BytesRef -> there is no check logic.
CharSequence -> (!IndexableFieldType#stored() &&
IndexableFieldType#indexOptions() == IndexOptions.NONE) should be false.
Reader -> (IndexableFieldType#indexOptions() == IndexOptions.NONE ||
!IndexableFieldType#tokenized()) and (IndexableFieldType#stored()) should be
false.
In fact, I worried about using the Number class when writing this patch.
I think API users may prefer int, float, double, ... rather than the Number
class.
What do you think about this?
{quote}Maybe use Objects.requireNonNull for the null checks?
{quote}
I made it by referring to the current code structure.
That method generates the NullPointerException, and current structure is the
IllegalArgumentException.
> Support numeric value in Field class
> ------------------------------------
>
> Key: LUCENE-8870
> URL: https://issues.apache.org/jira/browse/LUCENE-8870
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Namgyu Kim
> Priority: Major
> Attachments: LUCENE-8870.patch
>
>
> I checked the following comment in Field class.
> {code:java}
> // TODO: allow direct construction of int, long, float, double value too..?
> {code}
> We already have some fields like IntPoint and StoredField, but I think it's
> okay.
> The test cases are set in the TestField class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
