Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olemis@gmail.com designates
 209.85.223.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJpvC4J7hd+xe6Nkf-0uS0bc3OHjJYHCaN_oMq3Mno1y1t6GgQ@mail.gmail.com>
References: 
 <CAGMZAuOGjWHdSAZ5rTv9kZCVjnwY_YWSUzEkjbFtC6=qv-tb5A@mail.gmail.com>
	<CAJpvC4+g7N=_4XsAx2wFr__M86GALZd_7A1GcP=UgTQ5dcMcrw@mail.gmail.com>
	<CAGMZAuOuRkP1cV1+YPpC1k-+Q-912ZAPRfE5EwtF7nDRJg8b5A@mail.gmail.com>
	<CAJpvC4+v+gqaL6GZhuF3YCMM00mUe7S8UQqKqgn1G4HbLa=P6w@mail.gmail.com>
	<CAGMZAuN=avK4qrN93qOUph2K59UDeX4JRB1=ijfToh8hxYd8Nw@mail.gmail.com>
	<CAJpvC4L0xJiOQHqY=suNSCwxNwOc0bL2+cK9aTB6zvri1OMy_Q@mail.gmail.com>
	<CAJSKAsiBiCDoMZwPFGxVwnBMmGB4O-jzJnEZoCqAjc6wpwUekQ@mail.gmail.com>
	<CAJpvC4J7hd+xe6Nkf-0uS0bc3OHjJYHCaN_oMq3Mno1y1t6GgQ@mail.gmail.com>
Date: Mon, 28 Jan 2013 13:27:49 -0500
Message-ID: 
 <CAGMZAuP1PmcxOFOCBVFHXutHdCP8rvdzTHC-2sLfaMZij2nFFQ@mail.gmail.com>
Subject: Re: Approach to track of plugin upgrades WAS: svn commit: r1437357 -
 /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct/api.py
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1/28/13, Jose Angel Franco Navarro <jangel.franco@gmail.com> wrote:
> Hi Peter and Olemis,

:)

I'm getting rid of top-posting

> 2013/1/28, Peter Ko=C5=BEelj <peter@digiverse.si>:
>> I got a bit confused with the wording so would like to clarify:
>>
>> 1. Plugin should have one or one per component
>> BaseEnvironmentSetupParticipant correct (as not one per version)?
>
> 1. Each plugin would have a single specialization of
> BaseEnvironmentSetupParticipant. The idea is to change the class that
> now implements IEnvironmentSetupParticipant to make her extend
> BaseEnvironmentSetupParticipant and provide the required methods.
>

The code snippet in here might help to understand the whole idea .

https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0005#reference-impl=
ementation

So plugin developers are free to implement a single component
responsible for updating the database and environment or multiple
components . The BEP is only about the reusable framework to abstract
the interactions needed to carry out upgrades .

>> 2. The BaseEnvironmentSetupParticipant::get_db_setup_contributors()
>> speaks
>> of db scripts but actual upgrades are contained in modules. Should this
>> actually be get_upgrade_modules()?
>
> 2. I would rather prefer to change the docstring, not to limit the
> scope of the function in the future.
>
[...]

I'm +0 about this . I'd just suggest to be consistent and keep source
code readable .

>> 3. What is the benefit of having new tables separate from the free db
>> upgrades?
>
> 3. The benefits would be code reuse and higher testability of the
> environment upgrade. Once the algorithm to create the schema is
> stable, the plugins only provide data structures properly filled.
> Repetitive code to create the tables is placed in a single place and
> plugins only provide what is variable (their schema information).
>

I also add that it's helpful because there are well-know recovery
strategies to deal with failures at table creation time . OTOH , while
performing free upgrades (... and notice that I did not say *free db
upgrades* considering the fact that other side effects outside DB are
allowed as well in that particular case) it is much more difficult to
recover from an error condition . Summarizing , it is possible to try
free upgrades only after asserting that no issues regarding DB tables
will be found .

>> 4. If we have special support for db upgrades, have you considered havin=
g
>> something for ini files as well (I imagine plugins will be adding
>> new/updating configuration entries as well)
>>
>
> 4. Not evaluated till now, contributions accepted ;-)

In advance I would not do so . My reasoning is the following

At initial plugin installation there should be no strong reason for
setting options explicitly . The =C2=ABright=C2=BB approach is to provide
default=3D... keyword arg in option definition and let the configuration
subsystem to fall back to this value at run-time . There's no need to
add a new entry in ini files to make related option work .

Later on , while performing incremental upgrades site admins might
have already set the values they want , and IMO the upgrade process
should not be messing around and conflict with explicit admins
decisions .

Anyway , if someone provides a use case , I could change my mind on
the subject . We could add that later too if it proves to be really
useful .

--=20
Regards,

Olemis.