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:
http://svn.apache.org/viewvc?view=rev
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
fair.
(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
www.iktek.com
directory.apache.org
