The analysis settings have no relevance in non-text fields. If you look at
all the subclasses of AbstractFieldMapper, you will notice that only
StringFieldMapper, AFAIK, uses the analysis settings (besides the "no"
setting of course).
Thanks Ivan. So is there any reason to specify "index":"not_analyzed" for
those field types?
On Wednesday, October 2, 2013 12:40:49 PM UTC-4, Ivan Brusic wrote:
The analysis settings have no relevance in non-text fields. If you look at
all the subclasses of AbstractFieldMapper, you will notice that only
StringFieldMapper, AFAIK, uses the analysis settings (besides the "no"
setting of course).
Cheers,
Ivan
On Wed, Oct 2, 2013 at 9:30 AM, Hugh Williams <hughbi...@gmail.com<javascript:>
wrote:
I have a number of numeric, date, and boolean fields in my index. I'm
considering a mapping for them that specifies "index": "not_analyzed".
Is there any reason I'd want to analyze document fields that are supposed
to contain numerics, booleans, dates, etc?
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
Correct, there is no reason to set the field as non_analyzed since it is
indexed and not tokenized by default.
As I was looking at the code myself, I noticed that the boolean field is
tokenized by default. I was about to submit an issue, but I noticed I has
been fixed already (I am on version 0.90.2).
Thanks Ivan. So is there any reason to specify "index":"not_analyzed" for
those field types?
On Wednesday, October 2, 2013 12:40:49 PM UTC-4, Ivan Brusic wrote:
The analysis settings have no relevance in non-text fields. If you look
at all the subclasses of AbstractFieldMapper, you will notice that only
StringFieldMapper, AFAIK, uses the analysis settings (besides the "no"
setting of course).
I have a number of numeric, date, and boolean fields in my index. I'm
considering a mapping for them that specifies "index": "not_analyzed".
Is there any reason I'd want to analyze document fields that are
supposed to contain numerics, booleans, dates, etc?
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@**googlegroups.com.
Hi Ivan - A follow up question on this is how one should then search for
numbers: say if we search for 100.0 and 100, it should both yield same
result.
thoughts?
-Amit.
On Wed, Oct 2, 2013 at 10:50 AM, Ivan Brusic ivan@brusic.com wrote:
Correct, there is no reason to set the field as non_analyzed since it is
indexed and not tokenized by default.
As I was looking at the code myself, I noticed that the boolean field is
tokenized by default. I was about to submit an issue, but I noticed I has
been fixed already (I am on version 0.90.2).
Thanks Ivan. So is there any reason to specify "index":"not_analyzed" for
those field types?
On Wednesday, October 2, 2013 12:40:49 PM UTC-4, Ivan Brusic wrote:
The analysis settings have no relevance in non-text fields. If you look
at all the subclasses of AbstractFieldMapper, you will notice that only
StringFieldMapper, AFAIK, uses the analysis settings (besides the "no"
setting of course).
I have a number of numeric, date, and boolean fields in my index. I'm
considering a mapping for them that specifies "index": "not_analyzed".
Is there any reason I'd want to analyze document fields that are
supposed to contain numerics, booleans, dates, etc?
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.