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.
Cheers
Chris
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.
the column labeled ‘id’ for User and Group should not be a magic
auto-set auto-incremented column. That will be fixed in a future
version of the mysql/pgsql schema. It’s perfectly safe and correct to
change those column definitions.
the Principals table is the canonical source for those integers.
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.
It’s not completely redundant. It’s historical and there are several
queries that still use it. It’s slated for future destruction, but that
didn’t make the cut for the 3.0 stable series
Cheers
Chris
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.