Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAGMZAuP1PmcxOFOCBVFHXutHdCP8rvdzTHC-2sLfaMZij2nFFQ@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>
	<CAGMZAuP1PmcxOFOCBVFHXutHdCP8rvdzTHC-2sLfaMZij2nFFQ@mail.gmail.com>
Date: Tue, 29 Jan 2013 07:47:31 +0100
Message-ID: 
 <CAJSKAsiEe2xBU0sopNmrTBme+HGz+jZjW9k8yrfLWAE2dKQdEg@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: =?UTF-8?Q?Peter_Ko=C5=BEelj?= <peter@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8fb1f07c8d4b0404d467c492

--e89a8fb1f07c8d4b0404d467c492
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 28 January 2013 19:27, Olemis Lang <olemis@gmail.com> wrote:

> 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-im=
plementation
>
> 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 thi=
s
> >> 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
> having
> >> 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 .
>

Sometimes there just isn't sensible default value and admin just has to
fill in the blanks.
The second case would be when plugins comes to a point where configuration
reorganization is needed
and upgrade can use the old config values to enumerate new ones
automatically.
But I would agree that this two rare cases alone do not justify a framework
for this.


>
> --
> Regards,
>
> Olemis.
>

--e89a8fb1f07c8d4b0404d467c492--