bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Angel Franco Navarro <>
Subject Re: Approach to track of plugin upgrades WAS: svn commit: r1437357 - /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct/
Date Wed, 23 Jan 2013 17:32:23 GMT
Basically the work that has been done is a reusable mechanism to
implement upgrades for trac’s plugins based on trac's
IEnvironmentSetupParticipant infrastructure.

The design emulates the way trac does with its system upgrades keeping
separate files for each db upgrade version. The main rationale has
been: not having to touch a plugin’s db upgrade version once it is
working. If a new version is to come, changes should be provided in a
new db upgrade module (as trac does).

Another intention has been that of simplifying as much as possible the
plugins concrete work regarding the environment upgrade.

The mechanism consists of a base class called
BaseEnvironmentSetupParticipant from which some class in our plugin
must extend. It expects its specializations to provide four methods
that are conveniently used as the plugin upgrade process needs them
(recalling GoF’s Template Method), take a look at the code for further
clarification on the way they are used:

The four methods to provide are:
1. get_db_system_key : To return the the value of the key used to
store  the current plugin's version number in the 'system' table of
2. get_plugin_name : Returns the plugin's name to be used in the
logging messages   during the current environment setup process
3. get_plugin_version: to return the exact db version number  for the
current plugin installation (the current version of the plugin)
4. get_db_setup_contributors : returns a list of db setup script
names, E.g. (‘bhdashboard.upgrades.db0’, ‘bhdashboard.upgrades.db1’).
The mechanism here gives the plugin a chance to explicitly indicate
the setup scripts that must be used for the setup process.

 We have DashboardSystem class successfully  using the mechanism here:

A db setup contributor script must accomplish the following contract:
They must provide:
1 A function to indicate new tables to add to the schema. The returned
structure is expected to be similar to trac.db_default.schema
2 A function to indicate initial data to insert into the database. Its
return value must be like the one returned by
trac.db_default.get_data() function.
3 A function to perform any free db upgrade as needed.

For t140 the corresponding setup contributor script indicated by
DashboardSystem is here:

We have also implemented test cases for incremental plugin upgrade and
full plugin upgrade scenarios.  You can take a look at them here:

Sorry I couldn't meet the *briefly* condition  :-(

Best regards,

2013/1/23, Olemis Lang <>:
> On 1/23/13, <> wrote:
>> Author: jure
>> Date: Wed Jan 23 11:59:38 2013
>> New Revision: 1437357
>> URL:
>> Log:
>> Properly keep track of database versions, upgrade schema accordingly
> <jftr>
> As part of work made for #140 , Franco has developed a
> micro-architecture to keep track of these sort of upgrades . We've
> been running it since some weeks ago in some deployments we've made .
> </jftr>
> @franco : could you enlighten us provide links + detais and *briefly*
> explain what is it about ? As you can see there might be some interest
> on it , and this might get committed sooner than your solution for
> #140 .
> Thanks in advance
> --
> Regards,
> Olemis.
> Blog ES:
> Blog EN:
> Featured article:

View raw message