[
https://issues.apache.org/jira/browse/YARN-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15265424#comment-15265424
]
Sangjin Lee commented on YARN-4447:
-----------------------------------
{quote}
Spaces in the expression will have to be encoded while sending them in URL.
Colons were being used in previous expressions. If I am not wrong even in
ATSv1. It should be fine in query params I think. Colons are reserved
characters only in the scheme section of URI as per my understanding.
java.net.URI does not seem to have any objections with colons in query param
either.
{quote}
I'm fine as long as the expectation is set that clients/users escape spaces.
Ack on the colon.
{quote}
If you are talking about converting the whole expression to lower case, we
cannot convert the whole string to lowercase. Because
configs/metrics/events/info will have to be taken as-is. The reason being we do
not convert them to lower case when we write them to backend.
{quote}
That's a good reason. However, you didn't mean that we write the expressions in
the queries to the backend, right? We're talking about reading the values from
the storage as is and comparing them to the query expression as is?
{quote}
Sure, will add a note in javadoc. Had to make them mutable because I wanted to
set the variables as I was parsing the expression. Maybe you can have some
alternate suggestion when you go through the parsing code.
{quote}
If we were to avoid mutable filters, we would need to delay constructing the
current filter until the value is successfully parsed. It doesn't look very
obvious whether that is doable given the current shape of the parser code.
Making the filters mutable is a-ok, just be explicit about what it shouldn't do
(vis-a-vis HashMap/HashSet).
{quote}
Basically I just do not want to check for OR but also reject the expression if
ORR comes in place of OR. If code is confusing to read, I can consider changing
it.
{quote}
*Specifically* for checking for OR and AND, I believe it should be completely
equivalent to {{expr.toLowerCase().indexOf("or ", offset) == offset}}. I am
fine either way, though, as I don't think it is a serious issue.
{quote}
Wanted to check if metric values can have non numerical and non integral values
and if it has reject it while parsing itself. We can defer the checking to
storage layer as well though and in that case it can be moved back to
TimelineStorageUtils. Thoughts ?
{quote}
I understand the reader code now wants to use it, but it should be able to use
it from {{TimelineStorageUtils}}, right? I would be in favor of keeping it in
{{TimelineStorageUtils}} and have the reader code use it.
> Provide a mechanism to represent complex filters and parse them at the REST
> layer
> ----------------------------------------------------------------------------------
>
> Key: YARN-4447
> URL: https://issues.apache.org/jira/browse/YARN-4447
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: YARN-2928
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Labels: yarn-2928-1st-milestone
> Attachments: Timeline-Filters.pdf, YARN-4447-YARN-2928.01.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
