Grouper Developers Forum

[David Langenberg <>]

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