Grouper Developers Forum

[Jim Fox <>]

(a) is what we do also.

Jim


On Thu, 27 Oct 2011, Chris Hyzer wrote:

> Date: Thu, 27 Oct 2011 10:41:06 -0700
> From: Chris Hyzer 
> <>
> To: Tom Zeller 
> <>,
>  Grouper Dev 
> <>
> Subject: RE: [grouper-dev] [ldappcng] edge use-case : deleting the last member
>      from openldap
>
> I vote (a)
>
> -----Original Message-----
> From: 
>
>  
> [mailto:]
>  On Behalf Of Tom Zeller
> Sent: Thursday, October 27, 2011 1:18 PM
> To: Grouper Dev
> Subject: [grouper-dev] [ldappcng] edge use-case : deleting the last member 
> from openldap
>
> Feel like commenting on an "edge" provisioning use case ?
>
> The OpenLDAP groupOfNames schema must contain the member attribute.
> Consequently, if a group has no members, the member attribute must be
> provisioned with a configured empty value, usually an empty string,
> "".
>
> When processing member deletions via the change log, the ldappcng
> consumer will need to either :
>
> (a) attempt to delete the member from the group, if the ldap
> modification fails, parse the error and retry with the empty value
>
> (b) before deleting the member from the group, perform a search to
> count the number of members to determine if the empty value is
> necessary
>
> (c) cache every provisioned object so that we know when to supply the
> empty value
>
>
> Any other options ?
>
>
> For (a), the error returned from OpenLDAP looks like "LDAP: error code
> 65 - object class 'groupOfNames' requires attribute 'member'".
>
> I think that (b) introduces lots of unnecessary searches.
>
> I think I might prefer (c), caching, by which I mean cache every
> provisioned object in memory, so that ldappcng knows when to supply
> the empty value.
>
>
> For now, shall we just go with (a) ?
>
> Thanks,
> TomZ