Thank you Brian and Binh for your comments!
The slight trouble with that approach is an ongoing mapping changes every
time we add another Id (guid field) to the json document and it is quite
often on the move.
One of the reasons I fell in love with ElasticSearch was it somewhat
schema-less approach.
The situation with Guid breaks this idealistic model, requiring to add
not-analysed mapping for every new field of type guid and if it has been
missed - reindex the type after deleting and adding mapping.
That's why I was wondering whether there are plans to add native support
for guid.
On Thursday, April 3, 2014 5:26:00 PM UTC-4, Binh Ly wrote:
>
> Brian is right, if you map your field as not_analyzed, then you can do
> exact case-sensitive matches on it, as well as term facets/aggregations and
> sorts. This applies to fields like IDs, Guids, or anything you can think of
> that you don't want tokenized:
>
> {
> "mappings": {
> "doc": {
> "properties": {
> "Id": {
> "type": "string",
> "index": "not_analyzed"
> }
> }
> }
> }
> }
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/15d0435b-f11c-47de-afc5-19fe414fac0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
