On 10/7/2010 1:36 AM, Carsten Klein wrote:
I assume I don't need to point out why having a Users table would make
it easier to cross-reference whether a user had the requisite
permissions and/or was in the requisite group.
What is wrong with the self recursive approach of the permission table?
The information is all in there.
Extracting information from that table into different tables would mean
introduction of extra reduncancy with not benefit in overall processing,
as you would still be required to iterate over the permissions/actions
granted for a given group or user thereof.
-- Carsten
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
problem. The argument for having an actual User table is that things
start to fall down when you start integrating all these different tables
that have their own use for 'User' into a broader system.
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.(?)
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.
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?).
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.
--------------
With regards to what Terje was proposing, I'd have to say that (IMHO)
it's too much of a departure from what Trac currently does. I'd be
interested in seeing if he can come up with some sort of working
prototype, but I'd have to throw my hat in with 'Show me the code' crowd
before I thought it was actually a good idea.
However, what I would be interested in seeing, and which I believe would
be far easier and more beneficial in the short term, is normalising and
cleaning up the current DB structure. Essentially, getting it into a
more sane, comprehensible form and moving as much of the underlying data
structures into SQL as possible, instead of implementing them in Python.
My personal beef is with the 'ticket_change' table and its use for
storing comments. From what I can tell, it's a fair mess that could be
neatened up quite a bit, especially since as of 0.12 we're now storing
revisions to comments as well. (Seriously, who's bright idea was it to
do /all/ that in the same table?)
I'd be willing to pitch in some of my time to help with that, and to
give suggestions on better ways to handle some of the other tables if
that's wanted, though I'll freely admit I've been dealing with Trac's
code for a lot less time than most people on here.
- Josh
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
