On 1/28/13, Jose Angel Franco Navarro <[email protected]> wrote: > Hi Peter and Olemis,
:) I'm getting rid of top-posting > 2013/1/28, Peter Koželj <[email protected]>: >> 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.
