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: [Apache Bloodhound] #404: Populate default schema on product addition
Date Sun, 24 Feb 2013 06:07:24 GMT
On 2/22/13, Jure Zitnik <jure@digiverse.si> wrote:
> On 2/22/13 4:48 PM, Olemis Lang wrote:
>> On 2/22/13, Jure Zitnik <jure@digiverse.si> wrote:
[....]
>> Environment setup process should be completely apart of product scope
>> . It's a TRAC_ADMIN tasks i.e. nothing to do with anything you'd like
>> to do in product scope . Besides it blocks system execution (i.e.
>> upgrade msg, DB schema modifications, revert on error , etc, etc, etc
>> ...) and we should not be doing such things ... or otherwise stated
>> TRAC_ADMIN should be doing that once and products will only be able to
>> use what is available in global environment , no more ...
>>
>
> First, I agree that the environment (global, that is) setup should be
> apart from product scope.
>

I'd agree *IF* upgrades at product scope would be desired .
Nonetheless I think they will cause a lot of trouble , so I'm strongly
against them . If we thing in terms of contracts then I strongly
recommend that the precondition for instantiating product environments
be «every setup step needed to make components work in product
contexts has been already performed» ... we'll sleep better at night
;)

> It's a bit of a different story on product 'setup'. Now, we agreed that
> the non multi-product aware components should have a separate view of
> the database. In addition to system resource tables (components,
> versions, tickets and such), this view also comprises of custom tables
> that the component might introduce. These tables are introduced (and
> later upgraded for that matter) from within IEnvironmentSetupParticipant.
>

This is the way I understood your approach [1]_

{{{
#!plantuml

@startuml

participant "esglobal : EnvironmentSetup" as esglobal
participant "cglobal : SomeComponent" as cglobal
participant "esproduct : EnvironmentSetup" as esproduct
participant "cproduct : SomeComponent" as cproduct

note over cglobal : cglobal.env = global environment
note over cproduct : cproduct.env = *some* product environment

== Global environment upgrade ==

esglobal -> cglobal : upgrade()
note left : Global tables as usual

== Product environment upgrade ==

esproduct -> cproduct : upgrade()
note right : Product-specific DB view

@enduml

}}}

If we are talking of such sequences then I'm -1

> So, if we want to have a separate set of component tables per product
> (this is what 'separate view of the database' implies),

Will these tables be extended with product prefix ?

> we should use
> IEnvironmentSetupParticipant interface and run it within the specific
> product scope. And this would normally happen when adding product.
> So
> from the non multi-product aware component perspective, adding a product
> would seem much like creating a new environment.
>

-1
that will be the source of many headaches

> Multi-product aware components on the other hand would be handled
> differently as I described in my mail yesterday...
>

I was thinking of anticipating upgrades i.e. something like this [2]_

{{{
#!plantuml

@startuml

participant "es : EnvironmentSetup" as es
participant "c1 : SomeComponent" as c1
participant "c2 : OtherComponent" as c2
participant ": Multiproductsystem" as mpsys

note over c1, c2 : Setup participants

== Global environment upgrade ==

note over es : In a few words the strategy consists in anticipating
upgrades needed for MP components.

es -> c1 : upgrade()
note right : Global tables as usual

es -> mpsys : upgrade()
note right
    1. Upgrades to core tables, if needed
    2. Upgrades existing plugin tables to multiproduct, if needed
    3. Replay MP-unaware upgrades performed in this very same upgrade
loop e.g. c1
end note

es -> c2 : upgrade()
note right
    Perform both global as well as multiproduct table upgrades
    for both MP-aware and MP-unaware components.
end note

note over es
    MP-aware setup participants will only need a single call to upgrade() .
    'Upgrade actions' being actually product initialization yasks will not
    be handled at upgrade time, but via product resource listeners instead.
end note

@enduml

}}}

... and thereby keep all this running in global scope . Whether other
interfaces are needed along the way (... in the middle , at the end ,
... ) and other similar details , I'd have no major objections .

.. [1] http://goo.gl/qfYQw

.. [2] http://goo.gl/VrSFW

-- 
Regards,

Olemis.

Mime
View raw message