How is this in any way more useful than the current DB layout? Just look for field='comment' and it seems the same to me? I would say there will be a lot of resistance to changing an existing table in a backwards-incompatible way without a major use-case that is currently overlooked.
--Noah On May 2, 2010, at 7:35 PM, Josh Godsiff wrote: > Hi folks > > I'm looking to do some things with comments which would be easiest if they > got normalised out of 'ticket_changes' into their own db table. > > What I'd propose as a DB schema is something like this: > > CREATE TABLE ticket_revision ( > ticket integer, > time integer, > author text, > comment text, > UNIQUE (ticket,time) > ); > > CREATE TABLE ticket_change ( > ticket integer, > revision integer, > field text, > oldvalue text, > newvalue text > UNIQUE (ticket,revision,field) > ); > > A couple of questions regarding this - firstly, would this be of any benefit > to the wider Trac community, or is there some particular rational behind the > current method of storing comments that would make this a not terribly useful > idea to others. > > Secondly, is it possible for Plugins to modify the schema of core DB tables, > or can they only create/edit their own? > > Thanks > - Josh > -- http://oxideinteractive.com.au/ > > -- > 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. > -- 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.
