Alec, sorry that I didn't realize you are in the core team.
Matthew, I think as long as adding/droping column from ticket_custom
is transparent to the end user, I don't think there is any problem.

As I mentioned before, the main reason I suggest this is if I add
several custom fields to ticket_custom and want to display all custom
columns in custom reports, i need severa left out join (the number of
left out join will be equal to the number of custom columns I want to
display) instead of just one as I suggested. Also, if I want to do
group, sum on my custom columns, things get more complex.

Anyhow, thanks again for the answer. I will bring this up to the
trac-dev mail list.

thanks again
chong








On 4/1/06, Matthew Good <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-04-01 at 13:15 -0600, chongqing xiao wrote:
> > I see your point, but why not let the customer change the schma of
> > ticket_custom?
> > It is a custom owned table any way.
>
> Because the user shouldn't be required to edit the tables by hand.
>
> > 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.
>
> As Alec mentioned before we're trying to encourage the use of the Query
> module instead of custom reports.  I don't think it's exceptionally
> difficult to use custom fields in reports, but maybe there's a need for
> some more documentation there.
>
> > 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?
>
> Well, Alec *is* part of the Trac team.
>
> Forcing users to alter the table manually to add/remove fields is not an
> option.  I also don't think we want to keep rechecking the schema
> against the fields defined in trac.ini to run ALTER TABLE as necessary.
> This would also be complicated by the fact that SQLite didn't support
> ALTER TABLE until recently, which is why all the upgrade scripts for
> Trac use a temp table to handle any schema changes.  We certainly don't
> want to start doing that every time the user changes the custom fields
> in trac.ini.
>
> If this needs further discussion it should take place on
> [email protected]
>
> --
> Matthew Good <[EMAIL PROTECTED]>
>
> _______________________________________________
> Trac mailing list
> [email protected]
> http://lists.edgewall.com/mailman/listinfo/trac
>
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac

Reply via email to