Grouper Users - Open Discussion List

[Chris Hyzer <>]

I can think of four ways to ensure uniqueness:

1. The hook that Gary mentioned... just do a query in the attribute to table 
to make sure the same one doesn’t exist with another group uuid.

2. Or you could make a new custom table which relates GID and group_UUID (and 
has a unique constraint on GID and on GID/group_UUID pair).  Still keep it in 
the attribute too.  When you do your hook, also check the table to see if one 
exists, and insert if not.  This way, since things are in a transaction, you 
cant have a duplicate.

3. Another way would be to make a DB trigger on grouper_attributes which 
checks on insert/update to see if one exists by another group and if so, 
blows up.

4. Have all 500 groups in one stem where the group extension is 
whateverUnix_123 [where 123 is the GID] (granted this will bring about other 
problems, like the UI might not work well...)  Maybe it could partition with 
10 groups per stem (or something like this):  so group 50 would be: 
whateverUnix5:whatever0.  Group 579 would be 
somethingElse5:whateverUnix7:whatever9.

I don’t understand why Grouper is assigning/maintaining the GID and the 
customer's system isn’t sending it to Grouper, does the OS originate/assign 
it?  Or do they change it in the group file once Grouper tells them what it 
is?

Im thinking about what we could do to Grouper if we wanted, we could add a 
col to the groups table in 1.5 which is unique and nullable where sites could 
assign an internal identifier...  this would solve the unique issue.  Though 
its not much better than one of the methods above.  I wonder if other places 
are interested in this.

> 
> The customer is the only party using the GID and will only ever be
> drawing information from the production system, so I wasn't planning on
> differentiating here. Am I missing something?

If you only have one env then it isn’t an issue.

Regards,
Chris