On Wed, Jun 26, 2013 at 4:49 PM, Olemis Lang <[email protected]> wrote:
> Hi Anze ! > > On 6/26/13, Apache Bloodhound <[email protected]> wrote: > > #539: Product-scope TracAdmin commands don't take effect until tracd is > > restarted > > ------------------------+------------------------------- > > Reporter: rjollos | Owner: olemis > > Type: defect | Status: accepted > > Priority: major | Milestone: Release 6 > > Component: dashboard | Version: > > Resolution: | Keywords: tracadmin command > > ------------------------+------------------------------- > > > > Comment (by astaric): > > > > Config values in Product Configuration are cached to avoid hitting the > > database every time the config is accessed. Cache for config option is > > invalidated only when this option is set using the same Configuration > > instance, which is not the case when configuration is being changed > using > > the trac-admin. > > > > Even if you are right in your reasoning about config it seems to me > that the problem is more complicated than that . I've been looking > into this for a while . Like I mentioned before a similar error > happens (running apache2) after renaming wiki pages using trac-admin . > There's no associated config value in that particular case afaict . > > > Trac uses changes times of its configuration files to detect changes and > > reload the configuration (it actually creates a new environment, see > > open_environment in trac.env). > > > > To provide similar behaviour for product configurations we would need to > > somehow detect that the changes were made to the configuration in the > > database. If could store last modification data as a special value in a > > bloodhound_productconfig table, but this would require a hit to the > > database each time a value is read from the config so simply disabling > the > > cache would be easier. > > > > What was the reasoning behind the decision that the product configs > should > > be stored in the database instead of the .ini files? File configs would > > allow us to reuse trac functionality for detecting modification of > > configuration. > > > > The initial design I had in mind included an interface for pluggable > config backends ... however Branko's suggestions make sense and > prevailed . > > > > > Anyway, I do not think that this issue is ready to be fixed before 0.6. > > + > let's reschedule it for "release 7" > objections ? None here, I was thinking similarly and haven't considered it a blocker for release 0.6
