You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/08/30 00:15:43 UTC
MODDN and replication
Hi guys,
we have a little issue in the way we handle a MODDN operation during
replication.
AFAICT, we use a special control to pass some informations to the
consumer, so that it can proceed with the Move and/or Rename.
I don't think it's necessary. We just have to send a SearchResultEntry
containing the modified entry, with a Modify type, and the consumer will
be able to determinate which kind of MODDN has been used (and if the old
RDN has been remove dor not.
This will work because the consumer always have the previous entry
locally, and will retrieve it using the entryUuid.
We don't need the control.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: MODDN and replication
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Aug 30, 2011 at 3:45 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> we have a little issue in the way we handle a MODDN operation during
> replication.
>
> AFAICT, we use a special control to pass some informations to the consumer,
> so that it can proceed with the Move and/or Rename.
>
> I don't think it's necessary. We just have to send a SearchResultEntry
> containing the modified entry, with a Modify type, and the consumer will be
> able to determinate which kind of MODDN has been used (and if the old RDN
> has been remove dor not.
>
this indeed is a cool idea
> This will work because the consumer always have the previous entry locally,
> and will retrieve it using the entryUuid.
>
> We don't need the control.
>
this control was my idea to solve the MODDN operation(for having the
new RDN, deleteOldRdn flag and the new superior DN),
I didn't think of leveraging the entryUUID fo performing a diff back
in the dark age of implementing RFC 4533
--
Kiran Ayyagari
Re: MODDN and replication
Posted by Howard Chu <hy...@symas.com>.
Alex Karasulu wrote:
>
>
> On Tue, Aug 30, 2011 at 1:15 AM, Emmanuel Lecharny <elecharny@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi guys,
>
> we have a little issue in the way we handle a MODDN operation during
> replication.
>
> AFAICT, we use a special control to pass some informations to the
> consumer, so that it can proceed with the Move and/or Rename.
>
> I don't think it's necessary. We just have to send a SearchResultEntry
> containing the modified entry, with a Modify type, and the consumer will
> be able to determinate which kind of MODDN has been used (and if the old
> RDN has been remove dor not.
Yes, exactly.
>
>
> That sounds very reasonable. I've always wondered why we needed this
> additional control. Maybe there's something I am missing is what I was thinking.
>
> This will work because the consumer always have the previous entry
> locally, and will retrieve it using the entryUuid.
>
> We don't need the control.
>
>
> That would be great because this is making us non-standard, deviating from the
> protocol.
>
>
> Best Regards,
> -- Alex
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: MODDN and replication
Posted by Alex Karasulu <ak...@apache.org>.
On Tue, Aug 30, 2011 at 1:15 AM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Hi guys,
>
> we have a little issue in the way we handle a MODDN operation during
> replication.
>
> AFAICT, we use a special control to pass some informations to the consumer,
> so that it can proceed with the Move and/or Rename.
>
> I don't think it's necessary. We just have to send a SearchResultEntry
> containing the modified entry, with a Modify type, and the consumer will be
> able to determinate which kind of MODDN has been used (and if the old RDN
> has been remove dor not.
>
>
That sounds very reasonable. I've always wondered why we needed this
additional control. Maybe there's something I am missing is what I was
thinking.
> This will work because the consumer always have the previous entry locally,
> and will retrieve it using the entryUuid.
>
> We don't need the control.
>
>
That would be great because this is making us non-standard, deviating from
the protocol.
Best Regards,
-- Alex