On 08/12/2013 05:34 PM, Henry Nash wrote:
Hi
I'm working on extending the pagination into the backends. Right now,
we handle the pagination in the v3 controller class....and in fact it
is disabled right now and we return the whole list irrespective of
whether page/per-page is set in the query string, e.g.:
Pagination is a broken concept. We should not be returning lists so long
that we need to paginate. Instead, we should have query limits, and
filters to refine the queries.
Some people are doing full user lists against LDAP. I don't need to
tell you how broken that is. Why do we allow user-list at the Domain
(or unscoped level)?
I'd argue that we should drop enumeration of objects in general, and
certainly limit the number of results that come back. Pagination in
LDAP requires cursors, and thus continuos connections from Keystone to
LDAP...this is not a scalable solution.
Do we really need this?
def *paginate*(cls, context, refs):
/"""Paginates a list of references by page & per_page query strings."""/
# FIXME(dolph): client needs to support pagination first
return refs
page = context[/'query_string'/].get(/'page'/, 1)
per_page = context[/'query_string'/].get(/'per_page'/, 30)
return refs[per_page * (page - 1):per_page * page]
I wonder both for the V3 controller (which still needs to handle
pagination for backends that do not support it) and the backends that
do....whether we could use wether 'page' is defined in the
query-string as an indicator as to whether we should paginate or not?
That way clients who can handle it can ask for it, those that
don'twill just get everything.
Henry
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
