[
https://issues.apache.org/jira/browse/YARN-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15773062#comment-15773062
]
Varun Saxena edited comment on YARN-5585 at 12/23/16 3:14 PM:
--------------------------------------------------------------
I personally do not think TimelineEntity equals should check against idprefix
(you havent done so in the patch as well). Because that would indicate that we
identify entity with id, type and prefix which I do not think we should be
doing.
Yes, REST API or the reader interface design should not be tightly coupled. We
should avoid taking decision at REST and reader interface layer due to storage,
unless unavoidable. I guess your concern is that if we were to throw an
exception we are taking that decision based on the fact that HBase storage has
idprefix in its row key which may not be true for some other storage system.
I am not too fixated on throwing an exception. It was just an option which I
suggested because I had a concern that if there is indeed a bug on the write
path, it may not be easily unearthed. But yes, it will be a very unlikely case.
Let us see what is the majority opinion. I am -0 on not throwing an exception
either in get entities or get entity call, Sangjin is +1. What do you and Li
think ?
Anyways I will review the patch for other things. Lets seek opinion of others
on above point.
was (Author: varun_saxena):
I personally do not think TimelineEntity equals should check against idprefix
(you havent done so in the patch as well). Because that would indicate that we
identify entity with id, type and prefix which I do not think we should be
doing.
Yes, REST API or the reader interface design should not be tightly coupled. We
should avoid taking decision at REST and reader interface layer due to storage,
unless unavoidable. I guess your concern is that if we were to throw an
exception we are taking that decision based on the fact that HBase storage has
idprefix in its row key which may not be true for some other storage system.
I am not too fixated on throwing an exception. It was just an option which I
suggested because I had a concern that if there is indeed a bug on the write
path, it may not be easily unearthed. But yes, it will be a very unlikely case.
Let us see whatever the majority opinion. I am -0 on not throwing an exception
either in get entities or get entity call, Sangjin is +1. What do you and Li
think ?
Anyways I will review the patch for other things. Lets seek opinion of others
on above point
> [Atsv2] Reader side changes for entity prefix and support for pagination via
> additional filters
> -----------------------------------------------------------------------------------------------
>
> Key: YARN-5585
> URL: https://issues.apache.org/jira/browse/YARN-5585
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelinereader
> Reporter: Rohith Sharma K S
> Assignee: Rohith Sharma K S
> Priority: Critical
> Labels: yarn-5355-merge-blocker
> Attachments: 0001-YARN-5585.patch, YARN-5585-YARN-5355.0001.patch,
> YARN-5585-YARN-5355.0002.patch, YARN-5585-YARN-5355.0003.patch,
> YARN-5585-YARN-5355.0004.patch, YARN-5585-workaround.patch, YARN-5585.v0.patch
>
>
> TimelineReader REST API's provides lot of filters to retrieve the
> applications. Along with those, it would be good to add new filter i.e fromId
> so that entities can be retrieved after the fromId.
> Current Behavior : Default limit is set to 100. If there are 1000 entities
> then REST call gives first/last 100 entities. How to retrieve next set of 100
> entities i.e 101 to 200 OR 900 to 801?
> Example : If applications are stored database, app-1 app-2 ... app-10.
> *getApps?limit=5* gives app-1 to app-5. But to retrieve next 5 apps, there is
> no way to achieve this.
> So proposal is to have fromId in the filter like
> *getApps?limit=5&&fromId=app-5* which gives list of apps from app-6 to
> app-10.
> Since ATS is targeting large number of entities storage, it is very common
> use case to get next set of entities using fromId rather than querying all
> the entites. This is very useful for pagination in web UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
