On Thu, Apr 09, 2009 at 05:23:45PM -0400, Erik Bray wrote: > > On Thu, Apr 9, 2009 at 8:26 AM, Jeff Hammel <jham...@openplans.org> wrote: > > > > I hope to write an interface, IComputedFieldProvider (or similar), soon > > which will fake computed fields with an ITemplateStreamFilter. A better > > solution would be to patch Trac core to do this. But yeah, its a common > > problem and its annoying to do. See (e.g.) the TracHoursPlugin for an > > example of this (field: totalhours). > > How would something like this work with queries/reports? That's the > main issue I haven't been able to resolve in trying to develop this > sort of functionality. The simple answer would be to store the > computed value of the field in Trac's DB, but how would it know when > to update the value?
There are two answers that I have been thinking about, neither one of which I'm fully satisfied with: 1. The more robust answer (though maybe still not robust enough): Whenever a /query or /report URL is hit, compute all of the computed fields, as well as doing this every time a /ticket URL is hit. The values are stored in the the Trac DB, specifically inside the ticket-custom table. This would be horribly slow for any sizable number of tickets. 2. The less robust answer: Only do this when individual /ticket URLs are hit. The /query or /reports get cached values. 2. is probably required, at least for my use-cases. You could imagine doing something more intelligent too: * caching fields every N minutes, e.g. with a cron job (if there's not a pluggable cron plugin -- I thought there was but have since been unable to find it -- it would be easy to write). * For /queries or /reports, filter by other criteria to get back the desired ticket set, then compute the computed fields for the remaining tickets and doing additional filtering by these computed values. * For each computed field, cache them on certain events. For instance, some might only need to be cached when the ticket is updated (method 2. above). Others might need to be updated on repository commits. Etc. * Some combination of the above. I admit there's no easy answer for the general case. The event-trigger criterion appeals to me the most, but its easy to see times when it wouldn't work. For instance, if a field requires data from an external service, you won't know when this data will be updated in general. Still, I'm encouraged to try to get something working :) Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
