[
https://issues.apache.org/jira/browse/YARN-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268644#comment-14268644
]
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
case.
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
(v6.3.4#6332)
