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 ? > We > can disable caching of config values - I do not recommend doing so. [...] -- Regards, Olemis.
