incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@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
Date Mon, 28 Jan 2013 18:27:49 GMT
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želj <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-implementation

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 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 «right» approach is to provide
default=... 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 .

-- 
Regards,

Olemis.

Mime
View raw message