As part of our efforts to port RT3 to Sybase, we are examining the process of creating Users and Groups in relation to the Principals table.
In every place that a User is created (User_Overlay::Create, User_Overlay::_BootstrapCreate) the Principal entry is created, then the User is created is the id set to match the id created for the Principal. This keeps the id of the Principal and the id of the associated User in sync. However, it does not appear that this is necessary, as the Principal table has a column – ObjectId – to hold the id of the associated User object. As it stands, the id and ObjectId column of the Principal table are redundant data.
All of the above is also true for the Group table.
Our problem in the Sybase port is caused by the attempt to write a predetermined value to the ‘Identity’ column of a table. Generally this is not allowed, and while there are ways to get around this restriction, they do not work in all situations and bring a number of undesirable consequences.
It seems to me the easy way to fix this is to reverse the order of Principal and User/Group object creation. If the User/Group object was created first, the Principal object could then be created with the ObjectId column assigned to the id of the newly created User/Group. Is there any reason why this would be undesirable?
The other option would be to change the definition of the id column in User/Group to be NOT NULL with no default and require that an id from a Principal be provided to create an entry in the User/Group tables. In this case, the Principals table ObjectId column is completely redundant, so why not eliminate it.