directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [shared-ldap] Changes and questions on LdifUtils
Date Sun, 11 Nov 2007 08:40:50 GMT
Alex Karasulu wrote:
> Hi Emmanuel,
> I started working on the ChangeLog service. As I started to work on it
> I began to use the
> LdifUtils.reverseXXX methods that you were kind enough to write for
> me.  I had a few issues
> and made some changes to it but I want to make sure these were OK with
> you.  I also have
> a few questions about a couple things ...
> First here are a set of my changes to the LdifUtils file and it's test case:
> Could you look at it while answering some questions for me?
> (1) I saw you used AddRequest, DelRequest, ModifyRequest, and
> ModifyDnRequest beans
>      to encapsulate the parameters in a single argument to these
> methods.  I felt that this
>      would couple the request objects with the operation so I broke
> down this single parameter
>      into several parameters.  This way I did not have to build these
> objects just to get the
>      reverse LDIF. Is this OK?
Perfectly OK. The coupling is a little bit heavy with AddRequest, etc. 
You did the right thing.
> (2) Do we need to make the Entry take multiple Controls for operations
> instead of just one?
I don't understand the question. What Controls are you talking about ?
> (3) Do we need to make the Entry take an LdapDN and not a String?  I'm
> thinking this may
>      be more efficient since on the server we'll try to parse and
> renormalize this stuff when
>      attempting to revert to a snapshot.  WDYT?
We are manipulating LdapDN into the server, so I guess using a LdapDN is 
> (4) In LdifUtils.reverseModifyDN() the original code seemed to hard
> code setting the deleteOldRdn
>      property on the LDIF entry it was generating rather than using
> the value from the
>      ModifyDnRequest argument.  Was wondering if this was in fact a
> bug? I presumed it might be
>      and while breaking up ModifyDnRequest into pieces I added the
> deleteOldRdn boolean
>      parameter.  I use this parameter now instead of calling
> entry.setDeleteOldRdn( true ) always.
It's not a bug, but we can optimize slightky the code. In any case, as 
you will have a newRdn, if we want to revert, we will have to delete 
this NewRdn to replace it with the previous RDN. If the operation is 
just a move (ie, we keep the same RDN, but have a newSuperior), this 
will be a blank operation, so we can also set the deleteOldRdn to false, 
but this is only an optimization.
>      Note that after I did this I noticed some test cases started to
> fail.  I fixed it but I don't know I
>      trust how I did it.  Could you review these changes to
> reverseModifyDN for me?  I don't trust
>      myself.
Np, will do.
> Thanks,
> Alex
> P.S. I might have the ChangeLog working by tonight - at least to test
> reverting which only
> uses add and delete operations.

cordialement, regards,
Emmanuel L├ęcharny

View raw message