Grouper Developers Forum

[Chris Hyzer <>]

What are examples of these cases?  I don't really like the idea since it 
kills the realtime for ~30 minutes, right?
Is this fixing an edge case where we should really just say "if you create a 
group, and delete it, and create it again, and rename it, in less than 1 
minute (or whatever causes this), that you can wait until the end of the 
day"?  Or is there a way to do a partial full sync (e.g. sync a group or a 
folder fully, but not the whole repository?)

Thanks,
Chris




-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Tom Zeller
Sent: Friday, November 04, 2011 10:49 AM
To: Grouper Dev
Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming stems 
with child groups ?

So, in general, I am thinking that a possible approach is to perform a
full-sync whenever the ldappcng change log consumer encounters a
change log entry that it can not provision incrementally. Otherwise,
there may be a variety of errors until a full-sync is run.

Thoughts ?

On Thu, Nov 3, 2011 at 12:30 PM, Shilen Patel 
<>
 wrote:
> The original ordering issue you mentioned is resolved now by the way.
>
> Thanks!
>
> -- Shilen
>
> On 11/3/11 1:20 PM, "Chris Hyzer" 
> <>
>  wrote:
>
>>Sounds good to me, if that's the way we go, lets open a jira for it for
>>2.2
>>
>>-----Original Message-----
>>From: 
>>
>> 
>>[mailto:]
>> On Behalf Of Tom
>>Zeller
>>Sent: Thursday, November 03, 2011 12:31 PM
>>To: Grouper Dev
>>Subject: Re: [grouper-dev] [ldappcng] change log ordering when renaming
>>stems with child groups ?
>>
>>So, how should we handle provisioning a renamed stem to ldap via the
>>change log ?
>>
>>Some (maybe most) ldap servers only allow non-leaf objects to be renamed.
>>
>>When renaming a stem with child stems and groups, we would need to
>>create the new stem structure, move groups via renaming, and then
>>delete the old stem structure. I would categorize this as non-trivial.
>>
>>My suggestion for 2.1 is that we say we do not support renaming
>>non-empty stems via the change log. A full-sync will create new
>>objects and delete old ones, rather than renaming or moving.
>>
>>Thoughts ?
>>
>>TomZ
>>
>>> Before you get too far, a quick check against my local openldap
>>> reminds me that some directory servers support subtree renaming, and
>>> others may not.
>>>
>>> For example, given
>>>
>>>  ou=stem,dc=edu
>>>   ou=child,ou=stem,dc=edu
>>>
>>> I cannot moddn ou=stem since it is non-leaf. And I cannot rename
>>> ou=child first since the parent does not exist yet. I would need to
>>> create a new ou=newStem, move ou=child over to it, then delete
>>> ou=stem. Which would not be renaming. I guess we care about renaming
>>> stems for Active Directory since access privileges may be assigned to
>>> ous, not sure.
>>>
>>> Hmm.
>>>
>>> On Wed, Nov 2, 2011 at 8:08 AM, Shilen Patel 
>>> <>
>>>  wrote:
>>>> I think the ordering is inconsistent.  I'll fix this to make the stems
>>>> come before the child objects.  Let me know if anybody is expecting the
>>>> opposite order.
>>>>
>>>> Thanks!
>>>>
>>>> -- Shilen
>>>>
>>>> On 11/1/11 7:48 PM, "Tom Zeller" 
>>>> <>
>>>>  wrote:
>>>>
>>>>>When a stem containing child groups is renamed via
>>>>>setExtension("newExtension"), the change log entries for group renames
>>>>>occur before the stem rename.
>>>>>
>>>>>This makes it difficult to rename child groups on a target ldap
>>>>>directory, since the renamed stem (i.e. the OU) has not been renamed
>>>>>yet.
>>>>>
>>>>>Is it possible to change the change log order ? maybe configurably ?
>>>>>
>>>>>Otherwise, I would need to gather all change log events for the stem
>>>>>rename context id, and reorder them somehow, shudder.
>
>