At 10:11 AM 3/23/2004, Chris Ridd wrote: >On 23/3/04 5:08 pm, Kurt D. Zeilenga <[EMAIL PROTECTED]> wrote: > >> At 02:12 AM 3/23/2004, Claude wrote: >>> Is walking bottom-up through a subtree deleting each leaf entry the >>> best way to delete the entire subtree? >> >> Well, by "walking bottom-up", I assume you mean using one-level >> searches to walk down and then delete entries on the way up. >> A better way, I think, is to do a single subtree search and >> then blast deletes for all leafs. As you get responses back, >> issue deletes for entry that becomes (by prior deletes) a >> leaf. > >That's quite neat, but you'll run into admin limit issues fairly quickly >unless you use paged results or similar.
Of course, you can run into the same problems using oneLevel searches. (Regarding paged results: I'd assume that any server which implemented paged results would apply the same restriction across the result set, not how you asked for the result set. (Seems a security hole if you allow paged results to bypass your server side administrative limits on a result set.) That is, paged results should not be viewed (though it often is) as a mechanism to go around a server-side limit, but a mechanism to "page" results. But I digress.) Another advantage of using a subtree-scope search is that you see all the continuation references up front and can start to chase them in parallel. >The other trick is knowing when you've got a leaf entry without waiting for >all the results. I'd suggest trying to retrieve the standard X.500 >(operational) attribute hasSubordinates (a BOOLEAN) or possibly the >non-standard (operational) attribute numSubordinates (INTEGER) from each >entry. This won't help if your server doesn't support these attributes, of >course. Or the server (supporting one or both of these attributes) is unable to provide the attribute in a particular case (it's not always easy for a server to determine if a entry it holds is a leaf). Kurt
