Forum access schema role id field (rid) should be INT(10) unsigned

INT(10) unsigned overflows INT(11) signed? Are you sure about that?

I think we need the negative rids...

In MySQL, specifying INT(11) does not change the fact that an INT is a 32-bit number. It still has a minimum value of -2147483648 and a maximum value of 2147483647. It is no different at all than INT(10), so if the Forum Access module requires negative rids for something, it needs to instead store them as BIGINT in the database in order to handle all possible rids in the role table. If negative rids are not needed, then the forum_access table should be updated to store them as INT(10) unsigned so that it can handle the established role table rid range from 0 to 4294967295.

Increasing priority on this, because Forum Access functionality is broken for half of all possible rids.

(I am also a Forum Access user who found the conflict due to the high rid values used by the Role Export module)

Nice try :-)

rids are sequential, i.e. they start at 0. If you reach 2G, then you're in a league of your own.

If Role Export uses rids >2G then it's doing something weird, and I'm not convinced that FA needs to support that, certainly not at the cost of slowing down queries for everyone.

Understood--Role Export is doing something weird. It doesn't use sequential IDs, rather some funny random generation method (probably an attempt to avoid collisions when importing from another system). But the point remains that the forum_access table is where the inconsistency is. The role table is the origin of the rid and establishes the data type as unsigned INT, so any foreign table referencing that field should also use unsigned INT to avoid this, if possible.

Does Forum Access use negative rids? If not, why not go unsigned? That shouldn't slow anyone down.

Thanks for considering this issue again--I certainly don't diminish the great work that has been put into this module.

I did not find any use of negative rids in FA, but this is not the point.

AFAIK, you are the second person with this issue since I took over this module in 2007. I don't know why merlinofchaos chose SIGNED when he originally wrote FA, but it has always been that way and worked fine for just about everyone.

I have no way to estimate how smooth or rough a change of the {forum_access} schema would go, and I'm not going to take that risk.

Feel free to change the schema in your database — it will probably work.

Yep, I've patched our schema and deployed an update, works fine for us.

If anyone else wants to fix this, add the following to your forum_access.install file and run update.php (note this is for Forum Access 6.x-1.8):

/**
 * Change the rid field to unsigned INT
 */
function forum_access_update_6108() {
  $ret = array();
  $ret[] = update_sql("
    ALTER TABLE {forum_access}
    MODIFY rid INT(10) unsigned NOT NULL default '0'"
  );
  return $ret;
}