[Date Prev][Date Next]
Re: server side sorting & paging?
First, let me clarify: I am not taking the side that this should be a
priority for the OpenLDAP project. I agree that it makes more sense to
sort on client side, have implemented it in the past, and am
implementing now in my software. It works fine and doesn't kill any of
my clients for result sets in the tens of thousands. In the servlet
world (I have separated my core library from servlets) I am even
planning to cache result sets so that various pages of sorted results
can be retrieved without searching again. In my post was merely
providing a client developer perspective on what is empirically viewed
by some as a deficiency in OpenLDAP vs. proprietary LDAP servers.
Howard Chu wrote:
It's certainly not a gut/rewrite/overhaul task.
1) Server Side Sorting
I couldn't say, so please forgive the bit of cheekiness.
2.2 supports paged results.
In my mind, paged results are of limited value
In my mind, you should have stopped right there.
Why? The point about correlating various syntaxes to appropriate sorts
is a key implementation consideration that this thread would otherwise
ignore. I recognize there is some value of paged results without
sorting, which is why I chose the qualifier "limited".
Clients should grab results
and use them or display them as they arrive, in realtime. I suppose that's
not great for HTTP clients, but HTML isn't fully interactive in the first
This point is misplaced. I personally handle results as you say, and
while HTML is what the browser eventually gets, a Java servlet container
"client" like I build on can involve some serious interactivity over the
course of a session (I manage sessions now, too).
> OpenLDAP's indexing mechanism doesn't preserve ordering information,
> so sorting of indexed attributes doesn't come for free. The server
> uses hashes for indexing, to save on storage requirements.
This clears a lot up, but what about when the schema specifies an
ORDERING for an attribute?
The only other thing I wanted to respond to is that the (sn=A*),
(sn=B*). As I recall, we would need to manually patch OpenLDAP before
building it in order to allow one or two letter filters. If that's still
the case (Ace's results seem to indicate such), I would think you'd want
to mention that gotcha anytime you sell that solution.
Thanks for responding. I'm still perfectly happy with things as they
are, so please don't think I was griping.