I see your point, but why not let the customer change the schma of ticket_custom? It is a custom owned table any way.
It won't be a problem for updating to new version of trac. It makes writing custom report with custom fields more easy and it is also more efficient. Also, the code to handle it would be very similar to how the (ticket) table is handled and should be very simple. Anyhow, I would love to help out with this change but it will great if anyone in the core team can comment on whether this is something will be considered? thanks chong On 4/1/06, Alec Thomas <[EMAIL PROTECTED]> wrote: > On Sat, Apr 01, 2006 at 10:44:56AM -0600, chongqing xiao wrote: > > Hi, Alec: > > > > What do mean it is not a good database design. > > table ticket_custom (ticket_id, progress, estimate) is a standard > > relational table. > > In fact, I think the way the current ticket_custom (id, name ,value) > > won't be scalable. > > What I meant by not being scalable is that Trac allows the user to > define any number of custom fields. How are you going to cater for that > with this table? It has 'progress' and 'estimate', what if a user wants > 'testers', or 'customers', etc. > > I assume you are proposing that the table be altered as users add/remove > custom fields? That is what I was referring to when I said bad database > design; updating your schema based on user configurable values. It seems > to me that your schema should not be modifiable on the fly by users. > > > (For example, if you have two custom field, to include them in the > > report, you need > > to do left out join twice and both left out join has to check both id > > and value of (name) column. > > > > if the table is like (ticket_id, progress, estimate), it will be one > > left join with (ticketid) no matter how many custom fields you have. > > > > Also, using (id, name, value), you have no way to specify the data > > type for each custom field. > > > > Could anyone in the core team to comment on what is the reason to use > > (id,name,value) > > schema? > > > > I checked the code, it seems it should be pretty easy to make > > ticket_custom works the same as standard ticket table. > > -- > Evolution: Taking care of those too stupid to take care of themselves. > _______________________________________________ > Trac mailing list > [email protected] > http://lists.edgewall.com/mailman/listinfo/trac > _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
