On 6/7/2010 1:46 PM, Noah Kantrowitz wrote:
On Jul 5, 2010, at 8:40 PM, Josh Godsiff wrote:
On 6/7/2010 5:24 AM, Noah Kantrowitz wrote:
Name one such system that expects users to write direct SQL? Not to
be rude, but this all sounds very much like it is coming directly
from a book about DB theory, not from a practical assessment of what
would help Trac improve. The only real bonus anyone has come up with
to "fix" our schema is that it would be easier to transition to
SQLAlchemy as an ORM. That has been a rather contested feature, and
as of yet I don't think any work has been done on it (SQLAlchemy as
a connection broker is a different thing entirely). DB performance
has never really been of major importance for Trac one way or the
other, mostly because our storage needs are rather simple in nature.
The current system hasn't particularly limited us or plugin devs
that I know of, so I'm not sure why this is even being discussed, it
seems like a pretty cut and dry issue to me. If you want to talk
about moving Trac to an ORM (SQLAlchemy, Storm, etc) thats a
different issue, but don't drag relational modeling and
normalization into it because those are really non-issues.
--Noah
Just my two cents, but my company has a fairly in-depth real-world
case where we wanted to extend the Ticket model, system, and a couple
of the related subsystems (specifically the changelog) in order to
meet our own requirements. We concluded that as Trac's codebase
currently stands, this would take too much time to be cost-effective,
and that the main reason for that was non-normalised tables.
(Specifically, the ticket_change table, and the complete lack of a
users table). Normalisation would have allowed me to roll out a good
solution in the space of a day or two - instead, I had to hack around
it with some fairly ugly plugin code just so we had 'something'.
I'll also add that proper normalisation would monumentally help our
company in achieving the level of multi-project support we'd like,
and greatly increase the chance of us being able to submit those
changes back as patches to the main Trac codebase.
I agree that users need to be a top-level construct, and that is
indeed planned for Trac. I don't see how that is a schema problem
though, its just a missing feature. Can you be more specific about how
a normalized schema for tickets would have helped? ticket_change has
an ID number that is effectively an FK to the ticket table's ID
column. The only reason it doesn't have an actual constraint is for
apparently historical reasons re: SQLite. The lack of a constraint
isn't what I would consider a major issue though, unless you intend to
rely on the DB for ensuing data validity (which usually leads to poor
UX since you can't generate context-aware error messages).
--Noah
This has been previously discussed here in the thread 'Normalise
comments out to their own table?', but in brief:
The specific instance involved us wanting to add the ability to make
Comments private by default (only visible to a specific group of users,
i.e. Devs), public for people outside that group (i.e. Clients), and
give Devs the option to make a comment public when posting it.
The problem with the Ticket_Change table is that it's also used to store
Comments, which are not changes to the Ticket (in the sense of the
Ticket Model), but an addition to the Changelog. Having comments in that
table makes it fairly prohibitive to try and attach attributes to them
(i.e. a public/private flag). In a normalised database, you'd likely
have pulled Changelog out into its own separate table, and had
ticket_change entries reference a specific element in the Changelog
table, causing the changes we wanted to make to be ridiculously simple
(just adding a column to either of the tables, depending on whether we
want specific changes, or entire changes hidden).
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.
- 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.
