[
https://issues.apache.org/jira/browse/FALCON-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110439#comment-14110439
]
Balu Vellanki commented on FALCON-166:
--------------------------------------
{quote}
The default behaviour shouldn't be return all instances. It can cause memory
issues. Any number like 10 is fine
{quote}
Are we assuming that user will never want all instances of an entity? If
default is not all and the user wants all instances, user will have to
repeatedly call getSummary while incrementing offset for each call until num
Instances returned is less than numResults. I think this would be too
cumbersome.
{quote}
On what basis, will you choose (startDate + 10 * frequency * frequencyTimeUnit)
OR (currentTimestamp)? Length will already control the number of instances to
return. It doesn't make any sense to compute end again depending on that
{quote}
If user wants N instances and end is not specified, end should be (startDate +
N * frequency * frequencyTimeUnit). Else, there wont be N instances scheduled,
so API wont be able to return N instances.
{quote}
If the new param length can control number of instances returned, why not set
end to now?
{quote}
When you refer to param "length", do you mean param "numResults"? It does not
control number of instances. If the number of results returned is large, user
can choose to view the first N results (numResults) starting at an offset.
> Instance status start and end dates are rigid and inconvenient
> --------------------------------------------------------------
>
> Key: FALCON-166
> URL: https://issues.apache.org/jira/browse/FALCON-166
> Project: Falcon
> Issue Type: Sub-task
> Components: webapp
> Affects Versions: 0.3
> Reporter: Venkatesh Seetharam
> Assignee: Balu Vellanki
> Fix For: 0.6
>
> Attachments: Falcon-Jira-166-v1.patch, Falcon-Jira-166-v2.patch,
> Falcon-Jira-166-v3.patch, Falcon-Jira-166.patch
>
>
> There are 2 annoying issues that was brought up by [~srimanth.gunturi] while
> working on FALCON-164. The use case is to get the status for a given entity
> for the past 1 or 2 or 3 or 7 days.
> 1. Instance status with out an end date fetches for a very small window
> Instance status take end date as optional but assumes one second from the
> start date which is too small a window.
> {code}
> private Date getEndDate(Date start, String endStr) throws FalconException
> {
> Date end;
> if (StringUtils.isEmpty(endStr)) {
> end = new Date(start.getTime() + 1000); // next sec
> } else {
> end = EntityUtil.parseDateUTC(endStr);
> }
> return end;
> }
> {code}
> May be assuming the current time might be appropriate instead.
> 2. The start date has to be on or after the start of the entity.
> If the user has created the entity 2 days back but specified the start date
> for looking at the instances in the past 7 days, it should fetch what is
> valid rather than complain that the start date is before the entity's start.
> This is quite unwieldy to work with in a dashboard use case. I'm not sure
> what the performance impact is for this API to be changed.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
