140332 - versioncache needs to be deleted on bug status changes

Status: RESOLVED FIXED

(Bugzilla :: Documentation, enhancement, P3)

Description

[erich liebmann]

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)

Comment 1

[Matthew Tuck [:CodeMachine]]

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.

Comment 2

[erich liebmann]

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.

Comment 3

[Gervase Markham [:gerv]]

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

Comment 4

[erich liebmann]

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 [1], bugzilla and a
commercial tool called trackrecord [2] 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 [3] and providing a quick graphical overview of the possible
transitions.

for further information please contact me.

[1] http://www.gnu.org/software/gnats/
[2] http://www.compuware.com/products/trackrecord.htm
[3] http://bugzilla.mozilla.org/queryhelp.cgi#status

Comment 5

[Matthew Barnson]

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.

Comment 6

[Matthew Barnson]

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...