Re: Add: ora_e in frontend->database flow (Was: commit: ldap/servers/slapd/slapi slapi_ops.c)

[Luke Howard <lukeh@padl.com>]

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

--