On 28 January 2013 19:27, Olemis Lang <[email protected]> wrote: > 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 . >
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. >
