On 6/7/2010 2:16 PM, Noah Kantrowitz wrote:
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'm not arguing that doing it the way I suggested wouldn't require
rewriting more than the model. What I'm saying is that if the system
were implemented using a normalised, relational approach (in-so-far as
possible), it would make changes like the one I suggested far more easy,
and probably make development in general far more fluid.
I also think we possibly differ on design philosophies - I would never
design a /schema/ to reflect the /system/. System design and
requirements should inform what is stored in the db and the relationship
between different data structures, certainly. However I don't believe it
should ever inform /how/ that data is stored. In my experience, it is
almost always better to design your data-structures in the best possible
way, and then build your system around that.
On the point about Plugins extending core tables, normalisation again
makes this easier - with a normalised structure, it's basically as
simple as adding a column directly via SQL. If you need/want some sort
of middleware to handle this, you could implement a simple version of
something like Rails Migrations.
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
Ok, that was possibly more a gripe about the inability to test against
groups instead of purely against permissions. Nevertheless, coherent
persistent user-data (i.e. in its own table, with an ID), would make a
number of other things easier. The system of storing user-data in
sessions never struck me as particularly intuitive, and I've come across
several instances (user preferences, filtering project listings by
user), where having a User model would have meant I spent about half a
day less time digging around trying to work out how Trac does things.
That half-day is the difference between 'can commit this back as a
patch/plugin' and 'Just finish it so you can move onto work people are
paying you to do.' Anyway, that's getting slightly off-topic.
- 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.
