[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

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?


Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it