[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: rs_modlist for modRDN
On Sun, 2006-01-01 at 19:27 +1100, Luke Howard wrote:
> >I have no objection, as those structures are only intended to provide a
> >clear interface between frontend and backends (and now overlays) for
> >internal purposes and do not need to strictly stick with the
> >specifications for a given op. Make sure the interface is clean enough
> >(e.g. who's in charge to free the modlist if it's not null).
>
> OK, committed to HEAD. The caller should free the modlist, eg.
>
> rs->sr_err = slap_modrdn2mods(op, rs);
> rs->sr_err = op->o_bd->be_modrdn(op, rs);
> slap_mods_free(op->orr_modlist, 1);
>
> This has proved useful for us for two things:
>
> (a) updating replication metadata on rename
> (b) updating tombstone-related attributes when tombstoning
>
> Overlays can access orr_modlist directly; SLAPI plugins can get at it
> via SLAPI_MODIFY_MODS.
Two comments:
1) test006 is failing on a rename issue; could it be related?
2) you're still doing RDN decomposition in the backend side of modrdn
essentially for logging purposes; I guess this could be avoided, right?
p.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------