Paged search results help needed

[miha]

Hi everyone!

I've had no trouble getting some paged data from my ldap server, but only when going "forward" - from the first page to the last.

How does one step back? Let's say from the 5th to the 4th page?

Should i keep track of all the cookies??

Any help appreciated!

Thanks!

[ulsa]

The trouble is that, to my knowledge, you can't go backwards using PagedResultsControl. You could store all previous pages locally, I guess, and just retrieve new pages when going forward to pages you haven't yet retrieved. It depends on your situation whether this is suitable or not.

However, there is another control concept known as VirtualListView (VLV), which supports going forwards and backwards in a very flexible way. Unfortunately, the complexity of the control is higher than for PagedResults. Not all servers support the VLV control. We have tested against Sun ONE, and it works fine. You'll find a first attempt at an encapsulation of VLV in the sandbox project in the buildable distribution or in Subversion.

[miha]

Hi..and thanks for answering..

That is pretty much how i figured it out (about not beeing able to go back).
But if ia store all of the cookies for the search as i go forward, i should be able to get the results (one cookie = one paged resultset? or something else?) simply by doing a paged search with any stored cookie?Am i missing something here?

And, performance wise, it should not be a big deal if i pre-fetch a few pages (let's say i retrive 30 objects per page) and memorize all of the cookies. In my environment, this would be acceptable. Then, as i approach the end of the pre-fetched pages, i pre-fetch a nother batch of them...

Again, is this a valid concept using PagedResultsControl and its friends?

[rasky]

I would suspect that re-using cookies (i.e. storing them for going backwards) might result in undefined behaviour, but you'll probably have to go back to the actual RFC, and possibly to your specific server documentation to know for sure.

The pre-fetch approach is of course possible, but in that case you might as well use a larger page size in the first place, right?

[miha]

Thanks for the reply...

I could use a larger FETCH page size, but if my VIEW page size is smaller than the FETCH one, i have to use some kind of view paging taglib, which is a big NO-NO for me (say 30 for view, 200 for fetch...)
I am trying to have a 1:1 relationship (FETCH:VIEW).
You are quite right about the cookies, no one can say for sure that the same cookie will always point to the same result set. Will test

VLV worth giving a try in your opinion?

[ulsa]

VLV worth giving a try in your opinion?

I think so, yes. It was created just because PagedResultsControl didn't solve the problem completely. It's very flexible, but unfortunately only supported by some servers. I'm not even sure it was accepted as an RFC. It could still be a draft.

[miha]

Tried VLV with my target environment.
Unfortunately, it seems that Tivoli Directory Server 5.2 does not support the Virtual List View control

I will try to do a mix of spring-ldap PagedResultsControl for fetching large result sets, and custom paging inside each large set. For me, there is no alternative.

Thanks to everybody who gave this some thougth...

[ulsa]

Good work nevertheless. Any feedback from whatever you achieve would be useful.

[zbhiwandiwala]

Hello,
Could someone let me know where VLV is located? I am connecting to AD on a Windows 2000 server.

I am not sure if VLV will work for me, but I want to give it a shot. The PagedResultsControl does not provide me with details about the totalResult size, is checking the cookie the only way to determine if there are more pages available.

[ulsa]

Our encapsulation of the VirtualListView (VLV) control is only available in our sandbox for the time being. The sandbox is where we place stuff we're trying out, but that's not yet ready for public release. You can browse the sandbox here. The control package is here.

And, yes, I believe checking that the cookie is non-null is the only safe way to determine whether there are more pages available.