Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Changing Grouper ID

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Changing Grouper ID

Chronological Thread 
  • From: Tom Barton <>
  • To: Thomas M Goerger <>
  • Cc: Chris Hyzer <>, "GW Brown, Information Systems and Computing" <>, "" <>
  • Subject: Re: [grouper-users] Changing Grouper ID
  • Date: Fri, 23 May 2008 16:13:09 -0500


Just now I used the following method to change the subjectId recorded for a member in the grouper_members table in my test instance of grouper:

m=MemberFinder.findByUuid(s, "<uuid>")

I verified that it worked exactly as it should by debug level logging, highlights of which are at the end of this message. I also verified by starting up a second gsh session (in a separate jvm), and looked at the member's subjectId. It was the changed value. So the change had to have been made in the database.


Thomas M Goerger wrote:
Thanks for the advice. I did manage to get the subject_id to update in
the database, and in the UI finally. A few notes though, and maybe
someone can tell me if I'm doing something wrong.

I wasn't able to get the name to change by using the grouper shell. I was
able to get the commands to run successfully, and was able to see the
change made within the shell. However, when I accessed the database after
making these changes, I didn't see any change to the subject ID there. Is
there something I need to do to push these changes through?

In order to make the actual change to the subject ID, I just hit the
database itself, and changed the subject ID using SQL commands. Fine for
what we need. But, in order for the UI to actually see the changes made,
I had to rebuild the UI completely. I'm sure that this wouldn't actually
be necessary. Is there another way to refresh what the UI is seeing in
the database short of rebuilding? I'm not certain how to just restart the
Grouper instance, which I'm sure would probably do it. However, this
brings up another question. Why would I need to restart Grouper at all?
Surely there should be an easy way to dump the cache that Grouper is
working off of, and force it to see a fresh view of the DB. Any way to do

I'm wondering if anyone has actually changed a subject ID in Grouper the
way we are. It doesn't seem like these problems have come up with anyone
else, from searching the Web, or from reading the list. Is this not
something that was expected to happen, or is Grouper just not built to
accomodate this?


Tom Goerger
University of Minnesota
Internet Services

Log snippets. First, the grouper event, and then selected debug-level hibernate details:

2008-05-23 15:31:27,094: [672c302d-9da2-4ec8-8b39-41a41e0525cf,'GrouperSystem','application'] changed member subjectId: uuid='b39241eb-7627-4004-982f-4228e9f0408b' old='t-9gsing' new='t-9gsing2' (44ms)

2008-05-23 15:31:27,058: opening JDBC connection
2008-05-23 15:31:27,079: Updating entity: [edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MemberDAO#00078c77194d609b01194d67020645d0]
2008-05-23 15:31:27,085: listing entities:
edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MemberDAO{subjectId=t-9gsing2, uuid=b39241eb-7627-4004-982f-4228e9f0408b, subjectSourceId=uc, subjectTypeId=person, id=00078c77194d609b01194d67020645d0}
2008-05-23 15:31:27,090: about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2008-05-23 15:31:27,090: update grouper_members set member_uuid=?, subject_id=?, subject_source=?, subject_type=? where id=?
2008-05-23 15:31:27,090: preparing statement
2008-05-23 15:31:27,091: Dehydrating entity: [edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MemberDAO#00078c77194d609b01194d67020645d0]
2008-05-23 15:31:27,091: binding 'b39241eb-7627-4004-982f-4228e9f0408b' to parameter: 1
2008-05-23 15:31:27,091: binding 't-9gsing2' to parameter: 2
2008-05-23 15:31:27,091: binding 'uc' to parameter: 3
2008-05-23 15:31:27,091: binding 'person' to parameter: 4
2008-05-23 15:31:27,091: binding '00078c77194d609b01194d67020645d0' to parameter: 5
2008-05-23 15:31:27,091: Executing batch size: 1
2008-05-23 15:31:27,092: about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
2008-05-23 15:31:27,092: closing statement
2008-05-23 15:31:27,092: registering flush end
2008-05-23 15:31:27,092: post flush
2008-05-23 15:31:27,093: before transaction completion
2008-05-23 15:31:27,094: before transaction completion
2008-05-23 15:31:27,093: committed JDBC Connection
2008-05-23 15:31:27,093: after transaction completion
2008-05-23 15:31:27,093: aggressively releasing JDBC connection
2008-05-23 15:31:27,093: releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2008-05-23 15:31:27,095: after transaction completion
2008-05-23 15:31:27,094: Updating: edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MemberDAO#00078c77194d609b01194d67020645d0
2008-05-23 15:31:27,094: key: edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MemberDAO#00078c77194d609b01194d67020645d0
2008-05-23 15:31:27,094: Updated: edu.internet2.middleware.grouper.internal.dao.hib3.Hib3MemberDAO#00078c77194d609b01194d67020645d0
2008-05-23 15:31:27,094: closing session

fn:Tom Barton
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
title:Sr. Director - Integration
tel;work:+1 773 834 1700

Archive powered by MHonArc 2.6.16.

Top of Page