gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Gump and Database - and Changes in trunk
Date Fri, 03 Sep 2010 10:45:19 GMT
Hi,

Sander said he never managed to make Gump write to the database on
Clarus and on the new FreeBSD jail I saw the same, this should now be
fixed in trunk and I'll soon merge the changes to the live branch.

The underlying reason was that Gump never committed the changes it has
written.  vmgump and the old Solaris zone live on database backups
created many moons ago and my guess is their MySQL tables simply don't
support transactions so all changes get written through anyway.

Python's DB API explicitly states connection should not be in autocommit
mode, so if the database is transactional - which is what we seem to get
with more modern MySQL installations when we create a database from
scratch - any changes will get discarded when Gump finishes.  This has
now changed in trunk, Gump explicity commits its changes now.

On my journey to find the cause I discovered a few things, some of which
I don't understand so I'm describing them here in case Leo or Adam read
it or anybody else remembers the details.

In theory there are four "things" that interact with the database:

   * Statistician - this one provides the "duration in state" numbers
     and ultimately decides what goes on the "fixes" page and so on.

     Apart from the MySQL implementation there is a dbm backed one which
     is the reason why a MySQL DB is optional.

   * Databaser Actor - only runs if the --official switch has been
     specified and populates the tables gump_module_run and
     gump_project_run that are never read by anybody.

     What is this good for?

   * Dynagumper Actor - is registered if a database connection has been
     specified but doesn't do anything AFAICT.

     What is this good for?

   * Historical Database Actor

     Gump tries to use this actor in --official runs if the options say
     isHistorical().

     First of all there was a bug where there are two isHistorical()
     methods in options and one always returns true and the other always
     returns false - fixed in trunk.

     More importantly, its implementation is
     gump.actor.history.historical.Historical which simply isn't there,
     so registering it always fails.

     Does anybody remember what this was supposed to be and where it can
     be found?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message