Grouper Developers Forum

[Chris Hyzer <>]

I updated the docs.  Thanks!

> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Wednesday, October 22, 2008 9:40 AM
> To: Chris Hyzer
> Cc: Grouper Dev
> Subject: Re: [grouper-dev] done with "member change subject"
>
> 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...
> >