[
https://issues.apache.org/jira/browse/YARN-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185424#comment-15185424
]
Varun Saxena commented on YARN-3863:
------------------------------------
[~sjlee0],
bq. But I think the behavior hasn't changed regarding the last null. I think in
both cases the bytes will end with the separator.
Yes, inside {{getCompoundColQualBytes}} we in turn call Separator#VALUES so
effect will be same.
bq. I think the question is, should it be the behavior? If the user used a
non-equality filter, should the non-existence of that field be a match or not?
I can see arguments for either, but IMO returning those entities (that do not
have the field that is specified in the non-equality filter) seems reasonable.
What do others think?
Maybe we support both and let user specify if he wants to return the metric or
not.
Say a in default case in REST(in YARN-4447) we can have representation like
{{metric1 ne 40}} (means metric1 != 40 and metric existence is not required)
and {{metric1 ene 40}} (means metric1 != 40 and metric existence is required).
Thoughts ?
> Support complex filters in TimelineReader
> -----------------------------------------
>
> Key: YARN-3863
> URL: https://issues.apache.org/jira/browse/YARN-3863
> Project: Hadoop YARN
> Issue Type: Sub-task
> Affects Versions: YARN-2928
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Labels: yarn-2928-1st-milestone
> Attachments: YARN-3863-YARN-2928.v2.01.patch,
> YARN-3863-YARN-2928.v2.02.patch, YARN-3863-YARN-2928.v2.03.patch,
> YARN-3863-feature-YARN-2928.wip.003.patch,
> YARN-3863-feature-YARN-2928.wip.01.patch,
> YARN-3863-feature-YARN-2928.wip.02.patch,
> YARN-3863-feature-YARN-2928.wip.04.patch,
> YARN-3863-feature-YARN-2928.wip.05.patch
>
>
> Currently filters in timeline reader will return an entity only if all the
> filter conditions hold true i.e. only AND operation is supported. We can
> support OR operation for the filters as well. Additionally as primary backend
> implementation is HBase, we can design our filters in a manner, where they
> closely resemble HBase Filters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
