[Trac] Re: Dynamic pull-down population
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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
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 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
On Fri, Apr 10, 2009 at 10:29:33AM -0500, David Champion wrote: * On 10 Apr 2009, Jeff Hammel 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: I've taken a look at this kind of thing too, and my gut tells me that in these two proposals (as responses to this other poster's question) you may be attacking two separate but related problems at once. 1. There is a need for a provider interface for custom fields and their possible values -- an extension point to supplant [ticket-custom] in the config file. I agree: http://trac.openplans.org/trac/ticket/29 2. There is need for an extension which implements this extension point and may do roughly what you're talking about. I agree here too: http://trac.openplans.org/trac/ticket/28 I really need #1, but I don't need #2 at all. For my project I would deliver custom field definitions from an external source, and it wouldn't matter to me what values currently exist in the db, nor would I want to alter my db to store any of this information separate from the custom field values themselves. In my opinion, these are separate projects. Yes. 2. will build on 1. To me the best approach to #1 is a patch to trac.core. Sure, but I can write a plugin now instead of waiting for the patch to be in some Trac release. The patch should be written, but personally, I use plugins vs. patches whenever possible I don't see the value of implementing as an ITemplateStreamFilter except that you can currently do it as a plugin... but filtering the stream seems like a last resort when the basic functionality is already present. Yeah, not needed for 1., probably needed for 2. (or maybe IRequestFilter). However there's no existing extension point that you can tap into to offer the custom field metadata. The only custom field metadata source is currently hard-coded as [ticket-custom]. Yeah, I agree this is undesirable. If #1 is implemented as a new extension point in the spot where [ticket-custom] is now, then #2 is easily a separate plugin implementing that interface. Likewise, [ticket-custom] can be reimplemented as a plugin using that interface. Yeah, though I see no reason to redo [ticket-custom]. Its perfectly reasonable for people to put fields there, at least in the forseeable future (I can only think to maybe Trac 0.12 in my mindand barely at that) There are good examples of caching the field information already in trac.core -- [ticket-custom] itself illustrates this. None of these modifies the db itself, nor would it seem to benefit from doing so. 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
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). Jeff On Wed, Apr 08, 2009 at 10:45:15AM -0700, texnet196 wrote: Need to add 2 custom fields to create ticket. The first needs to populate via a remote mysql server query. The second needs to do the same and includes the chosen option from the first. Suggestions? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
On Apr 8, 12:45 pm, texnet196 brian.dowl...@gmail.com wrote: Need to add 2 custom fields to create ticket. The first needs to populate via a remote mysql server query. The second needs to do the same and includes the chosen option from the first. Suggestions? I think there are MANY people that would love to see this plugin. I would suspect the code that already populates the core fields would be a good template to look at. I have not idea, probably and ITicketProvider or something along those lines. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
On Apr 9, 7: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). Jeff snip actually, patching trac core to do this, IMHO, is a worse solution. That's what the provider interfaces are for.In reference to the better solution comment: I don't think you'd want an ITemplateStreamFilter, but promote your solution to something else here. Although, the solution you are working on has the merits of being one of the easier solutions, and might end up being more flexible to leverage to other tasks as well. Either way, I am curious to see your solution if you make it public. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
On Thu, Apr 09, 2009 at 08:40:12AM -0700, yoheeb wrote: On Apr 9, 7: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). Jeff snip actually, patching trac core to do this, IMHO, is a worse solution. That's what the provider interfaces are for. If you made 'computed' a custom field type, I think this is a big win for Trac. If there was an existing core provider interface to hook into that would be ideal, but there isn't :( My main reason for it being in core is to avoid Yet Another Stream Filter. In reference to the better solution comment: I don't think you'd want an ITemplateStreamFilter, but promote your solution to something else here. With existing implementation, I see no choice but to do an ITemplateStreamFilter or maybe a IRequestFilter to get the correct data into ticket.html. Of course, this doesn't fix searching and all of the other interfaces, so the computed field would have to be computed and cached for all requests that will need the field (again, another reason to do in core). Although, the solution you are working on has the merits of being one of the easier solutions, and might end up being more flexible to leverage to other tasks as well. Flexible? I'm not sure about. Easier? Yeah, that's why I'm doing it ;) Either way, I am curious to see your solution if you make it public. Will do. Hopefully will be done soon, as I (think I) need it for something else I'm working on. 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
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? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Trac] Re: Dynamic pull-down population
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 -~--~~~~--~~--~--~---
