From: Jon M. <jo...@te...> - 2006-03-08 15:40:57
|
The general idea of 'special groups' is that at install time you can decide to create up to (64?) groups which you know will very frequently occur in ACLs. As a user navigates the web site their membership of groups will be checked frequently. Since the user has logged in and is actively accessing the site you can be certain that the User record is loaded - because there is a reference to it in the httpsession object etc. So, since special group membership is coded in the User object, checking membership of the group requires no database access at all. The trade off is that although taking a user and finding out if they belong is quick, as Matthew points out, taking a special group and listing the users that belong is more difficult. A potential improvement would be to put a record in 'members' for all groups, including special ones, making sure that the two sources of data always agree. Jon Matthew Buckett wrote: >Paul Trafford wrote: > > >>At 15:09 08/03/2006, Antony Corfield wrote: >> >> >> >>>Can someone, Jon perhaps, remind me what special_groups_a etc. are >>>used for in users table? >>> >>> >>You can deduce memberships of the system generated groups. The total >>value is made up of components totted up from: >> >>2 allusers >>4 allstaff >>8 allstudents >>16 allothers >>32 campus.users >>64 campus.staff >>128 campus.students >>256 campus.other >> >>e.g. >>special_group a=102 => campus.staff, allstaff, allusers, campus.users >>special_group a=170 => campus.students, allstudents, allusers, campus.users >> >> > >I think User.addToGroup() and User.removeFromGroup do the dirty work. >They are used so that you can have very large groups without having a >large number of entries in the members table. One problem with them on >PostgreSQL is that you can't have an index on them that improves >performance when doing bitwise operations which means that the DB always >has todo a full table scan doing the bitwise operation for each row. > > > |