Hi Peter and Olemis, I will submit a diagram as olemis suggests to better show how the flow takes place. In the mean time I answer to Peter's questions here:
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. 2. I would rather prefer to change the docstring, not to limit the scope of the function in the future. Maybe It would be possible in the future to return as result of get_db_setup_contributors() module names but also object instances that accomplish the same contract... I'm not quite sure on this, but IMO whether the contributors are encapsulated in "modules" or something else, seems to be an implementation detail. get_upgrade_modules() do sound more self-descriptive though. Let me know what you think. 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). 4. Not evaluated till now, contributions accepted ;-) Best regards, Franco. 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)? > 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()? > 3. What is the benefit of having new tables separate from the free db > upgrades? > 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) > > Looks great otherwise, > Peter > > PS to Olemis: Whenever I leave your links to Blog EN/Blog ES in my replay, > Apache rejects my emails as SPAM. > > On 26 January 2013 00:12, Jose Angel Franco Navarro > <[email protected] >> wrote: > >> Hi everyone! >> >> I have just finished a first version for BEP-0005 documentation. >> >> https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0005 >> >> Best regards, >> Franco. >> > >> 2013/1/23, Olemis Lang <[email protected]>: >> > This is it >> > https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0005. >> > It's all yours . >> > ;) >> > >> > On 1/23/13, Jose Angel Franco Navarro <[email protected]> wrote: >> >> You may create the wiki page, >> >> >> >> I will make some time to explain everything down there. >> >> >> >> Best regards, >> >> >> >> Franco. >> >> >> >> 2013/1/23, Olemis Lang <[email protected]>: >> >>> On 1/23/13, Jose Angel Franco Navarro <[email protected]> >> >>> wrote: >> >>>> >> >>> [...] >> >>>> >> >>>> Sorry I couldn't meet the *briefly* condition :-( >> >>>> >> >>> >> >>> Yeah I noticed . Let's do this . I'll create a new Bloodhound >> >>> Enhancement Proposal for you to explain how this works . You'll have >> >>> a >> >>> whole wiki page to explain us probably with diagrams , images , etc >> >>> ... (only if necessary ;) and mention how that could be reused in >> >>> multi-product , search and other plugins besides dashboard , which is >> >>> the current target . >> >>> >> >>> @franco : Would you find some time to write this down for us ? Just >> >>> let me know to create that wiki page , please . >> >>> >> >>> However , notice that this doesn't mean your proposal will be >> >>> automatically accepted . In fact it may be rejected if it does not >> >>> satisfy the expectations of the project after further assessment ... >> >>> somehow . >> >>> >> >>> -- >> >>> Regards, >> >>> >> >>> Olemis. >> >>> >> >>> >> >
