Grouper Developers Forum

[Tom Barton <>]

We should probably emphasize that the operation is potentially time 
consuming only when two formerly separate Subjects are being merged into 
one, and that the time required is to replace the memberships of the 
formerly separate Subject that is being retired with new ones associated 
with the other Subject.

Chris Hyzer wrote:
> This is done.
>
>  
>
> https://bugs.internet2.edu/jira/browse/GRP-151
>
>  
>
> The use case is if you have a person who's subjectId changes, or if they 
> were originally put in the system wrong.
>
>  
>
> How it works is, if the new subjectId is not used in a grouper member, 
> it is simply updated in the existing member object.  If the new 
> subjectId does have a member object, then all references in the database 
> to the old member id, are updated with the new member id.  Then the old 
> member is deleted (though this is optional... you wouldnt remove if you 
> are having foreign key issues you want to get as far as you can without 
> failing).  In the API and GSH there is also a readonly dry-run mode 
> where you can see a printout of what will happen without executing it.
>
>  
>
> There is an API method, a web service, a GSH call, and some hooks to 
> customize it (e.g. if you use the member id, you can update your 
> reference too).
>
>  
>
> WS:
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/Member+change+subject
>
>  
>
> GSH:
>
> https://wiki.internet2.edu/confluence/display/GrouperWG/GrouperShell+(gsh)#GrouperShell(gsh)-Memberchangesubject
>
>  
>
> #############
>
> NOTES:
>
> #############
>
>  
>
> TASKS DONE:
>
> 1. test case for no member_id
>
> 1a. test case for member_id
>
> 1b. see that all objects are created correctly with a member_id
>
> 1c. test a duplicate membership, and a non-duplicate membership
>
> 1d. fix warnings or clear cache
>
> 2. code the member method (include transaction)
>
> 3. add a hook
>
> 3a. dry run
>
> 3b. test hook for member delete (never had one since we werent going to 
> delete members)
>
> 4. gsh method
>
> 5. gsh documentation
>
> 5a. gsh test case example
>
> 5b. run test cases
>
> 5c. put in retry handler everywhere
>
> 5d. Change web service client and server version
>
> 6. web service
>
>                 - Add in logic to GrouperServiceLogic for lite and batched
>
>                 - Add in SOAP calls from GrouperService
>
>                 - Add beans for 3 responses (batch single, batch 
> multiple, lite) and 2 requests (lite, batched)
>
>                 - Add in REST link to a URL
>
>                 - Make beans marshalable in xstream
>
>                 - Add rest-lite, rest-batch, soap-lite, and soap-batch 
> test cases and examples
>
>                 - Run the samples
>
>                 - Document on the web services wiki:
>
> 7. update bug
>
>  
>
> Columns that use grouper_members.id
>
> grouper_composites.creator_id
>
> grouper_groups.creator_id,
>
>                 modifier_id
>
> grouper_members.id
>
> grouper_memberships.member_id,
>
>                 creator_id
>
> grouper_stems.creator_id,
>
>                 modifier_id
>
> grouper_types.creator_uuid
>
>  
>
>  
>
> GSH commands:
>
> grouperSession = GrouperSession.startRootSession();
>
> oldSubject = findSubject("10021368");
>
> member = MemberFinder.findBySubject(grouperSession, oldSubject);
>
> newSubject = findSubject("10021366");
>
> member.changeSubject(newSubject);
>
> member.changeSubject(newSubject, !Member.DELETE_OLD_MEMBER);
>
> member.changeSubjectReport(newSubject, Member.DELETE_OLD_MEMBER);
>
>  
>
>  
>
> ISSUES:
>
> 1. If there are millions of entries to be updated, you might want to do 
> this:
>
>                 a. Rename subjectTo to subjectFrom.
>
>                 b. Remove subjectTo. 
>
>                 c. Rename subjectFrom to subjectTo (since it doesnt 
> exist, there will be fewer updates).
>
> 2. All queries occur in one transaction, so if there are lots of 
> updates, lots of memory will be needed
>
> 3. If you do a change operation, and someone adds the old member to a 
> group soonafter, then unexpected things might happen (will the old one 
> resurface?  will an error occur?).  Might want to revisit the member 
> table after the rename (1 hour at least) to make sure the old one didnt 
> resurface from cache or concurrent use...

begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technologies
email;internet:
title:Sr. Director for Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard