About Delete operation

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

LDAP protocol does not allow someone to delete a full tree with a delete
operation. Microsoft added a control (1.2.840.113556.1.4.805 - subtree
delete) to provide such a feature. ADS and OpenDS both support it.

My question is : should we have a specific deleteTree() method in the
API, or should we expect the user to add the subtreeDelete control to a
standard DeleteRequest in order to do the same thing ?

Right now, we have implemented a programmatic approach of the subtree
delete operation this way :
- if the server supports the subtree delete control, then send the del
request with this control
- else recursively delete all the children

This is a very costly approach, as there is no way to be sure that an
entry is a leaf or has some children but reading the entry (or trying to
delete each entry, and if unsuccessful, consider that the entry has
children, and recurse).

An alternative would be to either use the Control if the server support
it, or to throw an excpetion if it does not.

wdyt ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: About Delete operation

[Matthew Swift <Ma...@Sun.COM>]

On 04/02/10 17:44, Emmanuel LŽcharny wrote:
> [...]
>> Rather than recursing, you could do a subtree search from the base, 
>> retrieve only DNs, sort them in reverse order of reception (in OpenDS 
>> and DSEE parents are always returned before children entries) and 
>> delete them one by one. This is the scripted approach taken by many 
>> customers for servers that do not support the control.
>
>
> I agree. Let's the user send the control if he wants to delete a full 
> tree.
>


+1


Matt

Re: About Delete operation

[Emmanuel LŽcharny <el...@gmail.com>]

Ludovic Poitou a écrit :
> On Feb 4, 2010, at 4:42 PM, Emmanuel Lecharny wrote:
>
>   
>> Hi,
>>
>> LDAP protocol does not allow someone to delete a full tree with a delete
>> operation. Microsoft added a control (1.2.840.113556.1.4.805 - subtree
>> delete) to provide such a feature. ADS and OpenDS both support it.
>>
>> My question is : should we have a specific deleteTree() method in the
>> API, or should we expect the user to add the subtreeDelete control to a
>> standard DeleteRequest in order to do the same thing ?
>>     
>
> I don't think we want to encourage people to use the tree delete operation.
> It is dangerous and is often restricted to very specific accounts.
>
> So I don't think it is important to have a deleteTree method. Even more, I think it's preferable not to have one.
>
>
>   
>> Right now, we have implemented a programmatic approach of the subtree
>> delete operation this way :
>> - if the server supports the subtree delete control, then send the del
>> request with this control
>> - else recursively delete all the children
>>     
>
> Are you saying that this is your client side implementation of the deleteTree() method ?
>
>
>   
>> This is a very costly approach, as there is no way to be sure that an
>> entry is a leaf or has some children but reading the entry (or trying to
>> delete each entry, and if unsuccessful, consider that the entry has
>> children, and recurse).
>>     
>
> Rather than recursing, you could do a subtree search from the base, retrieve only DNs, sort them in reverse order of reception (in OpenDS and DSEE parents are always returned before children entries) and delete them one by one. 
> This is the scripted approach taken by many customers for servers that do not support the control.
>   

I agree. Let's the user send the control if he wants to delete a full tree.

Re: About Delete operation

[Ludovic Poitou <Lu...@Sun.COM>]

On Feb 4, 2010, at 4:42 PM, Emmanuel Lecharny wrote:

> Hi,
> 
> LDAP protocol does not allow someone to delete a full tree with a delete
> operation. Microsoft added a control (1.2.840.113556.1.4.805 - subtree
> delete) to provide such a feature. ADS and OpenDS both support it.
> 
> My question is : should we have a specific deleteTree() method in the
> API, or should we expect the user to add the subtreeDelete control to a
> standard DeleteRequest in order to do the same thing ?

I don't think we want to encourage people to use the tree delete operation.
It is dangerous and is often restricted to very specific accounts.

So I don't think it is important to have a deleteTree method. Even more, I think it's preferable not to have one.


> 
> Right now, we have implemented a programmatic approach of the subtree
> delete operation this way :
> - if the server supports the subtree delete control, then send the del
> request with this control
> - else recursively delete all the children

Are you saying that this is your client side implementation of the deleteTree() method ?


> 
> This is a very costly approach, as there is no way to be sure that an
> entry is a leaf or has some children but reading the entry (or trying to
> delete each entry, and if unsuccessful, consider that the entry has
> children, and recurse).

Rather than recursing, you could do a subtree search from the base, retrieve only DNs, sort them in reverse order of reception (in OpenDS and DSEE parents are always returned before children entries) and delete them one by one. 
This is the scripted approach taken by many customers for servers that do not support the control.


Ludo

> 
> An alternative would be to either use the Control if the server support
> it, or to throw an excpetion if it does not.
> 
> wdyt ?
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.nextury.com
> 
> 
> 

---
Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services          
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~