Vladimir, Even if ES supported a specific GUID field type, then it could still fail to be auto-detected.
I would think that you could detect when your data added a new guid field much more reliably than ES could auto-detect it. Note that you can easily update the mappings of an existing index in non-breaking ways, and one of these valid ways is to add a field that didn't exist before. I, too, liked ES's schema-less approach which made it easier to dive directly into and learn. But as time went on, I have finally locked down ES to never automatically create an index, and to never automatically map a field that doesn't already have an existing mapping. Combined with the cool ability to add mappings for new fields to an existing index, these make it easy to reliably catch new unexpected fields and then add the mappings for them without the chance of ES dynamically creating an incompatible mapping. Note that the auto-detection issue is the same whether ES supports a "guid" field type or whether you need to be a little more wordy and specify a "string" type that is indexed but not_analyzed. If you make ES guess, it can still guess wrong and define the new fields as "string" but with the standard analyzer. Brian -- 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/ff1cae6b-056b-49bd-9054-ea7ea954eabd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
