cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-5390) listNetworks: pageSize and page parameters are not applied properly
Date Tue, 24 Dec 2013 01:07:50 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-5390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13856066#comment-13856066
] 

ASF subversion and git services commented on CLOUDSTACK-5390:
-------------------------------------------------------------

Commit 632346d6a5ed1f50fbb160e2d25917f911c22d8a in branch refs/heads/4.3 from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=632346d ]

CLOUDSTACK-5390: when calculate index (page #) in NetworkManager, rely on fact that getStartIndex()
returned by API, returns pageSize*(page-1). So to get index(page), you need to do the reverse
calculation


> listNetworks: pageSize and page parameters are not applied properly
> -------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-5390
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5390
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.3.0
>            Reporter: Alena Prokharchyk
>            Assignee: Alena Prokharchyk
>            Priority: Critical
>             Fix For: 4.3.0
>
>
> ListNetworks call does numerous calls to the DB to get diff kinds of networks based on
search criteria (Isolated and Shared). The result sets are combined and returned to the API.
As page/pageSize parameters are passed only to the DB call, they are not respected while generating
the final set.
> There can be 2 ways to fix the problem:
> 1) generate only one call to the DB
> or
> 2) After the result set is finalized, apply the pagination to it. 
> I would go with #2 as changing the db call can introduce regressions plus its very hard
to achieve given the number of joins happening based on the search criteria. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message