On Fri, Apr 10, 2009 at 08:22:20AM -0400, Ted Gifford wrote: > > 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: > > How about defining several default policies for cache invalidation (such > as those listed below), and then allow plugins that define computed fields > to provide (via another interface?) their own policy own when to recompute > the field? > > Ted
Yeah, that would be the ultimate goal (though maybe with a callback instead of an interface?). Jeff > * > > *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 -~----------~----~----~----~------~----~------~--~---
