Good idea, that might work for the "inner" fields, however the "string" is 
always present so we'll still get the error.  I might play around with 
changing the mapping to try to adopt your solution if all else fails.. 

On Tuesday, December 9, 2014 6:11:02 PM UTC, David Pilato wrote:
>
> May be a filter agg using a exist filter could help?
>
> --
> David ;-)
> Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs
>
> Le 9 déc. 2014 à 19:01, Nuno Lopes <[email protected] <javascript:>> 
> a écrit :
>
> Hi David, Thanks for the reply.  
>
> Actually a more adequate example is below.  What we're trying to do is 
> apply the same aggregation over the different types even though we already 
> know some aggregations will fail (only using string and integer for this 
> example).   However, is there a way to ignore the ones that fail and have 
> the results for the valid aggregations?  The behaviour I'm finding is that 
> as long as one aggregation is invalid, we just get the error back.  And 
> would such solution also work over nested aggregations?
>
> POST /test/_search
> {
>    "aggregations": {
>       "a1": {
>          "max": {
>             "field": "value"
>          }
>       },
>       "a2": {
>          "max": {
>             "field": "value.integer"
>          }
>       }
>    }
> }
>
>
> On Tuesday, December 9, 2014 5:53:19 PM UTC, David Pilato wrote:
>>
>> If you want to compute on numerical values, you need to use the right 
>> field name.
>> value is a String. So you can’t use it for max agg.
>>
>> You could try with "value.integer". I think it should work.
>>
>>
>> -- 
>> *David Pilato* | *Technical Advocate* | *Elasticsearch.com 
>> <http://Elasticsearch.com>*
>> @dadoonet <https://twitter.com/dadoonet> | @elasticsearchfr 
>> <https://twitter.com/elasticsearchfr> | @scrutmydocs 
>> <https://twitter.com/scrutmydocs>
>>
>>
>>  
>> Le 9 déc. 2014 à 18:47, Nuno Lopes <[email protected]> a écrit :
>>
>> Hello all,
>>
>>
>> Consider the following mapping:
>>
>> PUT /test/value/_mapping
>> {
>>    "properties": {
>>       "value": {
>>          "type": "string",
>>          "index": "analyzed",
>>          "index_analyzer": "standard",
>>          "search_analyzer": "standard",
>>          "fields": {
>>             "integer": {
>>                "type": "integer",
>>                "ignore_malformed": true
>>             },
>>             "double": {
>>                "type": "double",
>>                "ignore_malformed": true
>>             },
>>             "date": {
>>                "type": "date",
>>                "ignore_malformed": true            }
>>          }
>>       }
>>    }
>> }
>>
>>
>>
>> with simply these documents:
>>
>> PUT /test/value/1
>>
>> {
>>     "value": "v1"
>> }
>> PUT /test/value/2
>> {
>>     "value": "2"
>> }
>>
>>
>>
>>
>> Writing this aggregation the whole response consists of a 
>> ClassCastException:
>>
>> POST /test/_search
>> {
>>    "aggregations": {
>>       "a1": {
>>          "terms": {
>>             "field": "value"
>>          }
>>       },
>>       "a2": {
>>          "max": {
>>             "field": "value"
>>          }
>>       }
>>    }
>> }
>>
>>
>>
>> When I'm writing this query I know this is the case but in my application 
>> I'm generating different kinds of aggregations (from which some will give 
>> ClassCastExceptions but I have no easy way of knowing which beforehand). 
>>  Is there a way to ignore an aggregation that is invalid and return the 
>> results of the ones which are valid? And similarly, would this work for 
>> nested aggregations? 
>>
>> Thank you, best regards,
>> --
>> Nuno Lopes 
>>
>> -- 
>> 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/09b76e9b-e956-4d61-9057-7aa4f655b4bc%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elasticsearch/09b76e9b-e956-4d61-9057-7aa4f655b4bc%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>  -- 
> 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] <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elasticsearch/290e9213-4df1-4383-a15f-4cb9b9c09a1b%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/elasticsearch/290e9213-4df1-4383-a15f-4cb9b9c09a1b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/8ef93efd-478c-430f-bd14-6eb2e16cfbc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to