> I'll concede there's nothing intrinsically wrong with it in the context > of it's own self contained purpose. I guess my actual beef with it is > there's no mechanism (that I know of) to check whether a User is in a > group, as opposed to has a permission, but that's more of a software
Here would be some queries for it, if you need them: All defined groups select distinct username from permission where username not in (select distinct action from permission); All defined users select distinct username from permission where username in (select distinct action from permission); Of course this will fail when you have users that also represent groups, or groups that are subgroups of other groups. Such users and groups will then be reported as users. As such, yes, a separate users table with an extra field used as a flag whether this is a group would be nice to have. > For instance, a User has permissions, and may belong to a Group, which > also has Permissions. Indeed, I believe that there is currently no > distinction between User and Group as far as that table is concerned.(?) Yes, you are absolutely correct. > However, a User may also have Preferences, Session information, and > probably many other kinds of data attached to them which is not a > Permission, which a group may not (does not?) have. One could suggest that a group might provide default settings for a user. > Having a user table would allow devs and plugin authors to easily attach > data to to users, and to cross-reference data across different tables > based on a particular user, since they could simply do JOINs across the > relevant tables instead of needing to mess around with whatever happen > currently (User object implemented in Python?). For sure, but then again, this could always also be accomplished by providing a plugin that would then manage a user/group table, with associated settings and so on. I believe that there is a plugin on trac-hacks that tries to solve that problem already. > From a purely normalisation basis, I need only point to the diagram on > http://trac.edgewall.org/wiki/TracDev/DatabaseSchema, and the > /ridiculous/ number of tables that have some sort of User field of type > 'text'. In terms of scalability, creating a User table and having other > tables reference an integer ID in it could /significantly/ improve > performance and use of space on large-scale installations. Hm, I do not think so. Yes, the redundant book keeping of the username can be a problem with backends that do not optimize on string storage. But since the username is a unique id, I think that it is correct in using it this way. Btw. what if a user deletes his or her account? As of now, the username will still be available, and no personal data whatsoever must be retained. As for the rest, I think that the proposal Terje made, can be summed up with what is meant to be the Generic trac approach, part of which was already documented in the wiki. Whilst being absolutely for the transition towards a more abstract storage schema, which would introduce object relations and allow addition of custom fields to near all domain objects that trac might know of (core and plugin provided), it will also raise the need of a revised database layer, which would then provide a generic CRUD access methodology and well defined behaviour. -- Carsten -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
