On Jul 5, 2010, at 9:02 PM, Josh Godsiff wrote:
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 will grant you that one, but I don't see that as a normalization
concern. I don't see how the schema itself caused a problem, it is the
entire design of how comments work (they aren't a top-level entity,
unversioned, etc). The schema reflects the system design, and does so
quite well. Normalizing the schema will do nothing without fixing the
rest of the system, and fixing the system doesn't require any systemic
changes to how our schema works. On top of this there is secondary
problem of how to allow plugins to extend core Trac tables with
additional metadata. This, again, isn't related to the schema, but is
a structural question that as of yet I've not heard a good answer to.
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.
The presence or absence of a user table (or user metadata system in
general) will not change permissions or groups in any way I can think
of. If you mean wanting to be able to do permission checks in SQL,
that isn't possible either way. Even without the context-based perms,
group lookups are recursive and SQL doesn't do that (unless you start
talking about login in SQL, and I certainly hope no one here is
suggesting that :-).
--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.
