I have one problem regarding dynamic fields and sorts and after reading about the "unmapped_type" parameter I'm not so sure I've understood how it works, as I don't see why it is necessary to specify the field type, or more important, what could happen if I set the wrong one.
I have several dynamic templates each of them being of a different type (text, integer, long...) but the user could try to sort by a field that may have not any document with a value. So, though there is a template for that field, it hasn't been mapped when the user requests the sort. In that case the user receives an exception as the field has no mapping associated yet.
Reading about the "unmapped_type" parameter I've seen I can avoid that exception as elasticsearch treats those fields that are unmapped as being of a certain type and every document in the index having no value for that field. I've even made some tests trying how it works with different types associated with different templates (string vs. string, integer vs. integer, integer vs. string...) and I have seen no difference, it works as expected not throwing an exception in any of the cases.
So seeing that it works as expected regardless of the type I use and given the fact that, for unmapped fields, it works as the field not having any value. I think I'm missing some point here, that makes it necessary to define the unmapped type instead of just using "ignore_unmapped=true" or something like that. So, what's the point of having a type? Could there be any problem for having a wrong type? Is there any type that works better regarding performance?
Thanks in advance