Naganarasimha G R commented on YARN-3009:

Hi [~zjshen],
     Thanks for pointing out the interface, i think we could add a test case 
which  could take any other object like List/MAP also .
bq. would it be sufficient if we did not perform the comparison with the 
original String when the resulting Object is a List or Map? Or do you think a 
different approach would be better?
As the resulting object can be of any object and not just List or Map it would 
not be feasible in this way but we can think the other way if the resulting 
object is subclass of {{java.lang.Number}}, then we can have the check which i 
have given earlier, but not sure even this approach can break in any other 
bq.I would expose a new parameter on the query that clearly states the value 
should be interpreted as an object.
This also seems to be a suitable alternate for this issue, like we can take the 
type of object[/flag indicating not  wrapper objects ] as the third field 
separated by a comma character. 
bq. better served instead of key=nested_object as 
path/to/attribute=literal_value (or a composition of them)
Did not get this can you give an example ?
[~zjshen] which approach would be better ?

> TimelineWebServices always parses primary and secondary filters as numbers if 
> first char is a number
> ----------------------------------------------------------------------------------------------------
>                 Key: YARN-3009
>                 URL: https://issues.apache.org/jira/browse/YARN-3009
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: timelineserver
>    Affects Versions: 2.6.0
>            Reporter: Chris K Wensel
>            Assignee: Naganarasimha G R
>         Attachments: YARN-3009.20150108-1.patch
> If you pass a filter value that starts with a number (7CCA...), the filter 
> value will be parsed into the Number '7' causing the filter to fail the 
> search.
> Should be noted the actual value as stored via a PUT operation is properly 
> parsed and stored as a String.
> This manifests as a very hard to identify issue with DAGClient in Apache Tez 
> and naming dags/vertices with alphanumeric guid values.

This message was sent by Atlassian JIRA

Reply via email to