Grouper Developers Forum

[Tom Zeller <>]

> What are examples of these cases?

For now, anything changing the name of a non-empty stem. So stem
rename and move, although copy might be ok. There may be other
ChangeLogTypeBuiltin events, but I have not got that far yet.

>I don't really like the idea since it kills the realtime for ~30 minutes, 
>right?

Depends on the deployment.

> 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?)

Do we consider stem rename or move an edge case ?

As of now, no, we do not have the ability to full-sync a branch of a
grouper tree, e.g. full-sync from a given stem and below. I am ok with
trying to implement a partial-full-sync or whatever, but it would take
some time to think it through.

TomZ

> 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.
>>
>>
>