Closed Bug 140332 Opened 22 years ago Closed 21 years ago
versioncache needs to be deleted on bug status changes
OVERVIEW DESCRIPTION the $BUGZILLA_HOME/data/versioncache file needs to be deleted if you modify the bug status (and probably the resolutions) enumeration within the mysql database to show immediate results. STEPS TO REPRODUCE follow the description at http://www.bugzilla.org/docs/html/dbdoc.html in section 2.1.1 bugzilla database tables ACTUAL RESULTS the updated/modified enumeration presented in the mysql database doesn't show up in the web interface EXPECTED RESULTS the updated/modified enumeration presented in the mysql database can be used in the web interface BUILD DATE & PLATFORM (not relevant for documentation component) ADDITIONAL BUILDS AND PLATFORMS (not relevant for documentation component) ADDITIONAL INFORMATION a checkout of the bugzilla project at Fri Apr 26 18:22:03 CEST 2002 still contains the documentation without the note to delete the $BUGZILLA_HOME/data/versioncache file the fact that bugzilla optimizes database lookups by storing static information in the $BUGZILLA_HOME/data/versioncache file is already documented in the bugzilla guide at http://www.bugzilla.org/docs/html/geninstall.html in section 3.5.1 modifying your running system. probably adding a paragraph similar to the following would be sufficient (this should undergo a proof reading since i am not a native speaker): make sure your bugzilla installation uses the modified values directly from the database by deleting the static information cache file $BUGZILLA_HOME/data/versioncache for further details please have a look at section 3.5.1 modifying your running system (should be a link)
This is not an officially supported action and it's not suprising it breaks, but I suppose a section on hacking things into Bugzilla would be useful.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
yes, absolutely! a special hacking section indicating not well tested, verified and understooden description with a warning/indication that it could break a production system following the instructions would be a good idea. on the other hand for the issue discussed (changing the resolution field) the fix/suggestion given in my bug report could be integrated into the documentation.
The docs on how and when to do this have been (temporarily) removed from the Guide on the branch completely, as they didn't fit where they were. We need to think about the appropriate place to add them back in. For my own reference, here's the SGML: <section> <title>Modifying Your Running System</title> <para>Bugzilla optimizes database lookups by storing all relatively static information in the <filename>versioncache</filename> file, located in the <filename class="directory">data/</filename> subdirectory under your installation directory.</para> <para>If you make a change to the structural data in your database (the versions table for example), or to the <quote>constants</quote> encoded in <filename>defparams.pl</filename>, you will need to remove the cached content from the data directory (by doing a <quote>rm data/versioncache</quote> ), or your changes won't show up.</para> <para> <filename>versioncache</filename> gets automatically regenerated whenever it's more than an hour old, so Bugzilla will eventually notice your changes by itself, but generally you want it to notice right away, so that you can test things.</para> </section> Gerv
note that the following may be off topic: actually i noticed the problem within the documentation during a detailed evaluation of the bugzilla bug tracking system for a seminar course at university. we (two study mates and i) evaluated GNU GNATS , bugzilla and a commercial tool called trackrecord  from compuware. if you are interested we could donate the document, slides and diagrams to the bugzilla documentation or add references to those documents. although the documents are nothing special they might be interesting for someone new to bugzilla. on the other hand there may be much better resources on the web. most interesting is probably a state chart in UML notation describing the bug status changes  and providing a quick graphical overview of the possible transitions. for further information please contact me.  http://www.gnu.org/software/gnats/  http://www.compuware.com/products/trackrecord.htm  http://bugzilla.mozilla.org/queryhelp.cgi#status
Erich: If you would please assign copyright on said documents to "Matthew P. Barnson and the Bugzilla Team", or place them under GFDL, I would love to have them for inclusion. We've had an FAQ for nearly three years basically indicating that we have no information on formal comparisons to other bug-tracking systems. Feel free to email me at my address included on this bug.
Gerv: I've added your text back to database.sgml. We have a major re-org due to the Guide before the next release, I'm thinking, so I'd really love it to be in there. Seems appropriate as well, considering the original bug was based off the information in that same file. That file does need a considerable amount of cleanup, I just realized that three-quarters of it is still contained inside a <literallayout> tag...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.