Pierangelo, >not sure if this is the case, but regarding ora_e overlays need to have >a slightly different behavior if they're global instead of per-database, >because at present the filed ora_e is set by fe_op_add(), that is >__after__ the global overlays are invoked. I didn't anticipate it to >do_add() because its generation in the original code occurred __after__ >the database was selected; I the reason was the need to exploit some >per-database restrictions or consistency checks. As a consequence,
Right, because the backend needs to be selected to determine whether it is the slurpd replication user or otherwise an update DN, and hence whether to add operational attributes and check for duplicate attributes. This is problematic for SLAPI global overlays because they no longer have access to SLAPI_ADD_ENTRY. The alternatives are: 1. Make slap_mods2entry() silently discard modifications that are already in the entry (that we it can be called first by the SLAPI overlay, and then by fe_op_add()) 2. Have the SLAPI overlay call slap_mods2entry() and then convert the entry back into a modification list; however this would break the 2.2 behaviour of SLAPI plugins being able to set operational attributes on add (which we need). 3. I had another idea but have forgotton it :-) -- Luke --
