Grouper Users - Open Discussion List

[Tom Barton <>]

Thomas,

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:

s=GrouperSession.start(SubjectFinder.findRootSubject())
m=MemberFinder.findByUuid(s, "<uuid>")
m.setSubjectId("newId")

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.

Tom

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
> this?
>
> 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?
>
> Thanks,
>
> 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

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