I'm guessing there's a logic reason for it, but I find it extremely annoying that the PagedResultsResponseControl is not available until the after the results have been walked through. This forces me to handle the list in some way at the point I'm making the LDAP request (when I wouldn't think the system would be aware of the object being worked on just that it's got a query) or have some way of going back for it (which makes the rest of the system have to be aware that it's working with LDAP and paging).
Spring has a solution for this I should look at more to see if I'm missing something.
Showing posts with label paging. Show all posts
Showing posts with label paging. Show all posts
Thursday, March 4, 2010
Tuesday, February 9, 2010
LDAP Paging
This struggle came up because I was trying to generically handle paging for either a relational database or LDAP repository, since the end user can choose either type to store their information.
Databases have several ways of handling paging, both within the query itself or, if it supports scrollable cursors, specifying the position of the cursor in the result set and getting a page of data from there.
I figured there must be something similar for LDAP repositories. Sadly, no. The closest in functionality was an RFC proposal for Virtual List Views. It wasn't accepted and while some Java API was developed for it in the JNDI booster back released for Java 1.4, I've been unable to find any updates for Java 5.
What there is something called Simple Paged Results (RFC 2696). The way it works is you specify the size of your page and the server will give you that many records and a cookie that you must pass in on future requests. You can't change the cookie, which means you're limited to only going forward. This seems a bit annoying when compared to database paging and I just figured there must be something that was equivalent.
Finally I started thinking about what I was using it for and why I would need bi-directional paging. The plan was to use this paging to get thousands to tens of thousands of records at a time. If there was a need to display small pages (like for a UI screen, then I'd let it worry about making smaller pages. The only reason I can see for needing to page backwards would be for a user at a UI screen.
How likely is it that someone is going to want (let alone need) to go through tens of thousands of entries and be able to page backwards? Something, tells me having a limit on the number of requests returned is just fine for the UI. For anything needing to get all of the data there's still the Simple Paged Results that will work just fine.
Glad I stopped fixating on the differences between RDB and LDAP paging and thinking about how it was going to be used...
Databases have several ways of handling paging, both within the query itself or, if it supports scrollable cursors, specifying the position of the cursor in the result set and getting a page of data from there.
I figured there must be something similar for LDAP repositories. Sadly, no. The closest in functionality was an RFC proposal for Virtual List Views. It wasn't accepted and while some Java API was developed for it in the JNDI booster back released for Java 1.4, I've been unable to find any updates for Java 5.
What there is something called Simple Paged Results (RFC 2696). The way it works is you specify the size of your page and the server will give you that many records and a cookie that you must pass in on future requests. You can't change the cookie, which means you're limited to only going forward. This seems a bit annoying when compared to database paging and I just figured there must be something that was equivalent.
Finally I started thinking about what I was using it for and why I would need bi-directional paging. The plan was to use this paging to get thousands to tens of thousands of records at a time. If there was a need to display small pages (like for a UI screen, then I'd let it worry about making smaller pages. The only reason I can see for needing to page backwards would be for a user at a UI screen.
How likely is it that someone is going to want (let alone need) to go through tens of thousands of entries and be able to page backwards? Something, tells me having a limit on the number of requests returned is just fine for the UI. For anything needing to get all of the data there's still the Simple Paged Results that will work just fine.
Glad I stopped fixating on the differences between RDB and LDAP paging and thinking about how it was going to be used...
Subscribe to:
Posts (Atom)