From bloodhound-dev-return-1674-apmail-incubator-bloodhound-dev-archive=incubator.apache.org@incubator.apache.org Wed Jan 23 17:32:51 2013
Return-Path:
X-Original-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 8D752E9D4
for ; Wed, 23 Jan 2013 17:32:51 +0000 (UTC)
Received: (qmail 53457 invoked by uid 500); 23 Jan 2013 17:32:51 -0000
Delivered-To: apmail-incubator-bloodhound-dev-archive@incubator.apache.org
Received: (qmail 53443 invoked by uid 500); 23 Jan 2013 17:32:51 -0000
Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: bloodhound-dev@incubator.apache.org
Delivered-To: mailing list bloodhound-dev@incubator.apache.org
Received: (qmail 53433 invoked by uid 99); 23 Jan 2013 17:32:51 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jan 2013 17:32:51 +0000
X-ASF-Spam-Status: No, hits=2.8 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_BLACK
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jangel.franco@gmail.com designates 209.85.212.52 as permitted sender)
Received: from [209.85.212.52] (HELO mail-vb0-f52.google.com) (209.85.212.52)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jan 2013 17:32:44 +0000
Received: by mail-vb0-f52.google.com with SMTP id fa15so4826957vbb.25
for ; Wed, 23 Jan 2013 09:32:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:in-reply-to:references:date:message-id
:subject:from:to:cc:content-type:content-transfer-encoding;
bh=EogaL0H+mHo9Kaw+IiRiX7SBMHuKekt1a8zH5h12SEg=;
b=0HFVF2y7on5rA9q5UBVqqGwC6/68bGeGJqWn9oNPfSN08XsqjeuLNTkdAmG5myo2V5
H+rmlGhNldZ79Ew8hl08OlqdaJaWxSHxqLsuZtX9XtKlQ5dymwUC5M2tRYP5eQqgucd8
KsKWAI1fUd1Z+Ot7vpgkqHPUzt4XFiBiCKeEhSzFaMeQ4qdttJqvRzxfDPHnsszKttz8
OC15PLQEq9+oKSs2FIC5cwun5Z+UhFBZvQKPN4+3Ire3tcJHlR0zwKj/Bs/zNlrlXRUp
31bkDNviQNsO1e92SmgsY00JNL1/dr9i4ZWFgazHxQZqEc/TEBvMVk5hwpJPtsDwGjyw
fLxA==
MIME-Version: 1.0
X-Received: by 10.52.174.71 with SMTP id bq7mr2011936vdc.49.1358962343945;
Wed, 23 Jan 2013 09:32:23 -0800 (PST)
Received: by 10.58.28.141 with HTTP; Wed, 23 Jan 2013 09:32:23 -0800 (PST)
In-Reply-To:
References:
Date: Wed, 23 Jan 2013 12:32:23 -0500
Message-ID:
Subject: Re: Approach to track of plugin upgrades WAS: svn commit: r1437357 - /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct/api.py
From: Jose Angel Franco Navarro
To: Olemis Lang
Cc: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org
Basically the work that has been done is a reusable mechanism to
implement upgrades for trac=92s 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=92s 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=92s Template Method), take a look at the code for further
clarification on the way they are used:
https://bitbucket.org/jose_angel_franco/bloodhound/src/2bb4b73cc75c7d2747eb=
b716bb833fe9a1c31750/bloodhound_dashboard/bhdashboard/env.py?at=3Dt140_dyna=
mic_layout_widgets_configuration
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
trac
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. (=91bhdashboard.upgrades.db0=92, =91bhdashboard.upgrades.db1=92=
).
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:
https://bitbucket.org/jose_angel_franco/bloodhound/src/2bb4b73cc75c7d2747eb=
b716bb833fe9a1c31750/bloodhound_dashboard/bhdashboard/api.py?at=3Dt140_dyna=
mic_layout_widgets_configuration
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
variable.
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:
https://bitbucket.org/jose_angel_franco/bloodhound/src/2bb4b73cc75c7d2747eb=
b716bb833fe9a1c31750/bloodhound_dashboard/bhdashboard/upgrades/db0.py?at=3D=
t140_dynamic_layout_widgets_configuration
We have also implemented test cases for incremental plugin upgrade and
full plugin upgrade scenarios. You can take a look at them here:
https://bitbucket.org/jose_angel_franco/bloodhound/src/2bb4b73cc75c7d2747eb=
b716bb833fe9a1c31750/bloodhound_dashboard/bhdashboard/tests/test_env_upgrad=
e.py?at=3Dt140_dynamic_layout_widgets_configuration
Sorry I couldn't meet the *briefly* condition :-(
Best regards,
Franco.
2013/1/23, Olemis Lang :
> On 1/23/13, jure@apache.org wrote:
>> Author: jure
>> Date: Wed Jan 23 11:59:38 2013
>> New Revision: 1437357
>>
>> URL: http://svn.apache.org/viewvc?rev=3D1437357&view=3Drev
>> Log:
>> Properly keep track of database versions, upgrade schema accordingly
>>
>
>
> 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 .
>
>
> @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: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>