Josh Godsiff wrote: > My personal beef is with the 'ticket_change' table and its use for > storing comments. From what I can tell, it's a fair mess that could be > neatened up quite a bit, especially since as of 0.12 we're now storing > revisions to comments as well. (Seriously, who's bright idea was it to > do /all/ that in the same table?)
The comment revisions were my fault. The driving forces that led to that result were: - Do not break any existing code. - Avoid a database upgrade, as (I thought) we were close to releasing. - As the comments were in that table already, having the comment revisions there didn't seem like a stretch. - Initially, we didn't want to keep older comment revisions at all, but in the end we found that it would be useful and we found a "cheap" hack to keep them. Looking back, it may have been easier (and certainly cleaner) to just add a table "ticket_comment_revisions" and store them there. Or anything else, really. I'd be really happy to see what a clean DB schema for the ticket functionality should look like. No new functionality, just the same as today but in a clean structure. -- Remy
signature.asc
Description: OpenPGP digital signature
