In Grouper 2.2+ the main Grouper objects in the database (groups, folders, attribute definitions, attribute names) will be assigned unique integers. These integers can be used for instance as gid's in unix.
The id's are not used anywhere else in Grouper, if you need to adjust them feel free, though the max index for an object type should never be more than the last index used in the grouper_table_index table (you can increment that).
Some reserved id's can be stored in memory so that the table does not need to be accessed for each object creation. By default non-GSH environments will reserve 10 at a time, and GSH will reserve 1 at a time. If Grouper is bounced while id's are reserved (common case), then those id's will never be used. Also, if transactions are rolled back, then id's will be wasted. Hence the id's are generally sequential and each id is used, but there will be gaps and they will only be sequential per JVM (even if the reserved size is 1).
The implementation is thread safe per JVM and across JVM's.
You can configure a group who's members are allowed to assign index id's on create in the grouper.properties. If this config property is blank then anyone can assign index id's on create
# group who can assign id index cols (also, wheel or root is allowed) grouper.tableIndex.groupWhoCanAssignIdIndex = etc:canAssignIdIndex
DDL
The Grouper 2.2 ddl will add large integer columns to the 4 tables: grouper_groups, grouper_stems, grouper_attribute_def, grouper_attribute_def_name. The DDL will also assign id's to the existing rows. Note, this column is non-null for new deployments of grouper, feel free to add that constraint to upgrades. There is also a grouper_table_index table with 4 rows which keeps track of which if the last index reserved. There is a unique index on the id_index col so no rows can have the same index.
Configuration
Configure this in the grouper.properties
grouper.tableIndex.group.minIndex = 10000 grouper.tableIndex.stem.minIndex = 10000 grouper.tableIndex.attributeDef.minIndex = 10000 grouper.tableIndex.attributeDefName.minIndex = 10000 # verify that table indexes are set and the pointers are ok, incurs a bit of overhead to grouper startup grouper.tableIndex.verifyOnStartup = true # in different circumstances, retrieve a different number of IDs at once. # if it is a system where the JVM is starting and stopping (e.g. GSH), then # dont reserve that many at once grouper.tableIndex.reserveIdsGsh = 1 grouper.tableIndex.reserveIdsDefault = 10 grouper.tableIndex.reserveIdsLoader = 10 grouper.tableIndex.reserveIdsWs = 10 grouper.tableIndex.reserveIdsUi = 10
Startup
On grouper startup, two things are checked. If there are rows with null id_indexes, they will be set to id's. If the last reserved index is less than the max index for that object type, it will be updated. If you do not want to perform these checks on startup, set this in the grouper.properties:
# verify that table indexes are set and the pointers are ok, incurs a bit of overhead to grouper startup grouper.tableIndex.verifyOnStartup = true
Import / export
ID indexes will export and import (if its a new record and the index isnt in use already), the last reserved index will be incremented appropriately. Note, if you import and there are other running JVMs, you might want to bounce them since they have indexes reserved in memory
API
There are API methods to lookup objects by ID index. e.g. GroupFinder.findByIdIndexSecure(idIndex, exceptionIfNotFound, queryOptions). Note, these methods cache by default, but you can stop the caching with queryOptions. Also there are: StemFinder.findByIdIndexSecure(), AttributeDefFinder.findByIdIndexSecure(), AttributeDefNameFinder.findByIdIndexSecure()
sdf