Grouper Developers Forum

[David Langenberg <>]

If you want such a constraint (uniqueness at the database layer) why not skip the INT datatype and use varchar?  Yes, storing essentially an integer as a string does rub wrong, but it seems future-proof at least from the outset.  I just worry that starting with INT will lead us to the same issue that we're having with IPv4 where sure in 1980 4 billion IP addresses seemed enough for anybody, but that sure doesn't cut it in 2012. 

Dave

On Wed, Apr 25, 2012 at 12:04 AM, Chris Hyzer <> wrote:

Well, the database column doesn’t have to be constrained to 4 billion, so Grouper wouldn’t break, but whatever is using that int might if it was using it for gid’s J

 

Penn has one of the larger deployments of Grouper, we have 3 million memberships and 100k groups, 2k stems, and 3k attribute def names.  We aren’t talking about giving ints to memberships, so based on those numbers, I think a high percentage of Grouper deployments would not hit the 4 billion mark for number of groups for a long time…  sound reasonable or no?  I was hoping to have a solution which had an easy way to have a database constraint to make sure the id’s are unique…

 

Thanks,

Chris

 

 

From: David Langenberg [mailto:]
Sent: Tuesday, April 24, 2012 6:16 PM
To: Chris Hyzer
Cc: Grouper Dev; Benn Oshrin
Subject: Re: [grouper-dev] gid/fid/aid

 

Won't that put a max-limit on objects in the database to be the system max int?  Doesn't seem like a workable ceiling until we get 128bit machines.  Even so, you still have enough 32-bit machines out there that it wouldn't be safe to allow any int greater than 2^32 for at least the GID case.  What would be more handy would be a special attribute type of say sequence which could be set on a group-by-group basis.  This would still cause a max-membership limit of system-max-int and for the GID case 2^32, but the constraint would be local to just that particular group rather than database-wide.

Dave

 

 

On Tue, Apr 24, 2012 at 3:32 PM, Chris Hyzer <>  wrote:

It seems like it would be useful if Groups/Folders/AttributeNames had a unique integer associated with them for that env for Grouper 2.2.

 

We could add a col and unique constraint and index to each of the three tables.

We could have a table with three rows which keeps track of the current index (could have minimum in grouper.properties).

A helper method could increment the current index for new objects in a new autonomous transaction (note, if transaction of new group is rolled back then the indexes for groups will not be consecutive).

Grouper startup could assert that the current index pointer is greater than the max index for each object type

Finding an object by id could accept either the UUID or integer (or we could make a new method to do this if we didn’t want to figure it out by the “type” of the id (string vs integer).

This value would be exported, and imported, unless there is a conflict on import, in which case the next available integer would be used (similar to how uuids work).

 

Does this solve the comanage issue and the gid issue?

 

Thanks,

Chris

 

 

--
David Langenberg

Identity Management

The University of Chicago

 

--
David Langenberg

Identity Management

The University of Chicago