one might be to use keywords instead of so many fields?
On 2 Mrz., 16:18, "Xie&Tian" <[email protected]> wrote:
> Sorry for double-posting the thread and thanks for your reply, Noah.
> I've discussed with our trac developer about this and it seems we
> don't have many options.
>
> --Xie
>
> 2009/3/2 Noah Kantrowitz <[email protected]>:
>
>
>
> > Yes, 20 custom fields is likely to cause issues. Given the limitations
> > of SQL there isn't really much of a way around this. Not sure I would
> > really classify this as "poor support" since it is well beyond the
> > expected use case. You could do some manual hacking and include extra
> > columns on the ticket table for what you need, but it would be a non-
> > trivial conversion. My vote would be to figure out why you need so
> > many fields in the first place and fix that instead.
>
> > --Noah
>
> > On Mar 1, 2009, at 8:08 PM, Xie wrote:
>
> >> Hi everybody
>
> >> The company I'm working at (www.kingsoft.com, if you understand
> >> Chinese :p) uses Trac heavily for bug/task tracking. There are some
> >> custom fields in the ticket and we probably will have more. As the
> >> design of Trac indicates, the support for custom field is poor and
> >> we're having doubts about Trac's performances with ten or even twenty
> >> custom ticket fields and >10k tickets. Has anyone the experience with
> >> this kind of problem? Any plan with compatibility to future Trac
> >> versions would be appreciated. Or perhaps we should customize more and
> >> maintain our own version of Trac instead?
>
> >> Ciao
> >> Xie
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
