[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Move SLAPI in an overlay...
- To: ando@sys-net.it
- Subject: Re: Move SLAPI in an overlay...
- From: Luke Howard <lukeh@padl.com>
- Date: Fri, 22 Jul 2005 12:45:57 +1000
- Cc: openldap-devel@OpenLDAP.org
- Organization: PADL Software Pty Ltd
- References: <200507210047.j6L0lt9o084318@au.padl.com> <53994.131.175.154.56.1121923027.squirrel@131.175.154.56> <200507211555.j6LFtVfv042169@au.padl.com> <48676.131.175.154.56.1121962256.squirrel@131.175.154.56> <200507211630.j6LGUeg4044737@au.padl.com> <48871.131.175.154.56.1121963825.squirrel@131.175.154.56> <200507220052.j6M0qYvh072105@au.padl.com> <42E04BD7.9040307@sys-net.it>
- Versions: dmail (bsd44) 2.6d/makemail 2.10
Does it make sense to provide frontend support for entry_get_rw()
too? If an overlay wants to call be_entry_get_rw() it won't work
unless it sets up the environment itself. I was thinking of:
int
fe_entry_get_rw(
Operation *op,
struct berval *ndn,
ObjectClass *oc,
AttributeDescription *at,
int rw,
Entry **e )
{
BackendDB *be_orig = op->o_bd;
int rc;
if ( be_orig == NULL ) {
return LDAP_NO_SUCH_OBJECT;
}
op->o_bd = select_backend( ndn, 0, 0 );
if ( op->o_bd->be_fetch ) {
rc = op->o_bd->be_fetch( op, ndn, oc, at, rw, e );
} else {
rc = LDAP_UNWILLING_TO_PERFORM;
}
op->o_bd = be_orig;
return rc;
}
int
be_entry_get_rw(
Operation *op,
struct berval *ndn,
ObjectClass *oc,
AttributeDescription *at,
int rw,
Entry **e )
{
int rc;
BackendDB *be_orig;
if ( op->o_abandon ) {
return SLAPD_ABANDON;
}
be_orig = op->o_bd;
op->o_bd = frontendDB;
rc = frontendDB->be_fetch( op, ndn, oc, at, rw, e );
op->o_bd = be_orig;
return rc;
}
But I wonder what kind of performance cost this might exact.
-- Luke
--