On Tue, Jul 06, 2010 at 01:40:21PM +1000, Josh Godsiff wrote: > 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
Hi Josh, thank you for speaking up as, I guess, the first person here to support my argument. IMO, you're spot-on in your assessments here and further down the thread. What is your opinion on the issue of major vs 12-step rewrite? I have a core "patch" that basically hacks together subsystems. Pass the env through a callchain to render wikitext somewhere, clone the custom field system here, hardcode a bunch of special cases there, hack in some poor date logic in model, middleware and javascript and debug until it appears to work etc. You simply cannot solve a problem of any signifficant proportions without changing large amounts of the existing codebase. This worries me, in terms of a 12-step approach to a system that is much more complex than what we have already. And, as you and I now seem to agree, there *is* a connection between this class of problems and the approach to data modelling, specifically whether the model is normalized or not. Was feeling very alone up until now;-) A key benefit of moving to a relational model, is that we attract a much wider audience, and thus get more help. This happens because people like Josh and myself and doubtless many others, can eventually reccommend the product for use in production environments, without a major up-front (re)development cost. Terje -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
