Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] done with "member change subject"

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] done with "member change subject"

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] done with "member change subject"
  • Date: Wed, 22 Oct 2008 08:40:03 -0500

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.

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







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









GSH commands:

grouperSession = GrouperSession.startRootSession();

oldSubject = findSubject("10021368");

member = MemberFinder.findBySubject(grouperSession, oldSubject);

newSubject = findSubject("10021366");


member.changeSubject(newSubject, !Member.DELETE_OLD_MEMBER);

member.changeSubjectReport(newSubject, Member.DELETE_OLD_MEMBER);


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

fn:Tom Barton
org:University of Chicago;Networking Services & Information Technologies
title:Sr. Director for Integration
tel;work:+1 773 834 1700

Archive powered by MHonArc 2.6.16.

Top of Page