directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: How to implement getIdentities(int start, int limit) more effectively
Date Fri, 03 Jul 2015 07:53:13 GMT
Le 03/07/15 08:49, Xu, Yaning a écrit :
> Kai,
> Thanks for your suggestions. It's good to me. 

My percezption is that the getIdentities() method should be made
specific, per backend. If a backend supports paged search and sort,
fine, iyt can use it. If it's not, then it should use a default
implementation. In any cases, the user should not be aware of what's
going on behind the curtain.

The best way to acheive this is to have the getIdentities() return a
Cursor, which can be handled by any client. This cursor will allow the
user to move forward or backward, regardless of the number of elements
in the cursor. You can have a look at the Cursor interface we are using
in ApacheDS :

Side note : in the SQL world, this is the same approach. Once common
mistake though in this world, when design (G)UI which expose pages of
elements taken froma  cursor is to proceed in two steps :
- first do a SELECT COUNT(*) WERE blah
- second, depending on the number of elements, proceed with a single
page, or manage pagination locally, with a second request to the server,
fetching the real entry.
This is *idiotic* ! Doing that, you make the server do the same work
twice : the SELECT COUNT(*) is as costly as the second request, and it's
totally useless, unless you really want to expose the number of elements
on the screen, which is rare. The rational is that when you do a normal
request, the Cursor API allows you to define the number of elements
you'll get back on the client side (default to 10, most of the time).
That means the cursor implementation on the client side will cache N
elements, no matter what, because the server will send N elements anyway.

All in all, define a getIdentities() interface, with an abstract
implementatiuon that fetches everything, and specific implementations
that bypass this abstract implementation.

View raw message