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
--
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.
