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 Mon, 25 Feb 2013 22:45:35 GMT
On 2/25/13, Jure Zitnik <jure@digiverse.si> wrote:
> On 2/24/13 7:07 AM, Olemis Lang wrote:
>> On 2/22/13, Jure Zitnik <jure@digiverse.si> wrote:
>> [....]
>>> 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
>> ;)
>
> Upgrades at product scope are not only desired but in my opinion
> actually required (see below). Please note that each custom (3rd party
> plugin) table is created *per product*.

Based on what I understand out of this such approach does not scale .
Think of a deployment of the scale of sourceforge , github , bitbucket
, and alike ... the number of tables in the DB will be O(p) ? IMO it
does not need that big to get us into trouble .

> Therefor create/upgrade also
> need to be handled per product.
>

The fact that we should handle things per-product does not mean that
we have to make them at product environment initialization time . Two
different things .

>>> 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]_
>>
[...]
>>
>> If we are talking of such sequences then I'm -1
>
> Yes, if I understood that sequence correctly, that's what I'm proposing
> (assuming cglobal is enabled in esglobal (global) environment only and
> cproduct in 'esproduct' (product) environment).
>

well the image actually represent two instances of the same
(component) class , and there will be only one per environment (i.e.
component manager)

>>> 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 ?
> Yes, table names are prefixed with product prefix.

I see , so I confirm my previous suspicion about that this is hard to scale up .

> As a consequence,
> each non multi-product aware component will end up with as many tables
> as there are products (+1 for null/global one), each table name being
> prefixed with product prefix. There is no other way of doing this as
> there is no way of knowing, what the actual schema/content of the tables
> is.
>

understood . What about having a plugin table for global env , another
'clone' for product envs and always translate the later using product
prefix by default ?

>>> 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
>
> It is my understanding and opinion that's the only way to move forward,
> excluding 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]_
>>
[...]
>
> Not sure what 'anticipating' would mean in this context.
>
[...]
> I'm not sure what the 'Replay MP-unaware upgrades' is supposed to mean
> and how to get from 'c1 upgrade' to replay?
>

Determine pending upgrades , instantiate plugin env participant on top
of each product env , and run upgrades ... all that in MP upgrade
method .

> Are we supposed to keep log of SQLs that the component executed during
> environment creation/upgrade? I don't think that's doable. Not to
> mention that not only the SQLs would be product specific (references to
> tickets or any other system table for that matter), but the component
> could also be, for example, creating files in env.path.
>

Yes . That's why I said replay ... What I mean is not to wait until
instantiating product env to perform its pending upgrades, but detect
such condition when MP system is performing it's own upgrade . That's
doable afaics

[...]
>
> The latter part (single call to upgrade() for multi-product aware setup
> participants + usage of product resource listeners) is what I proposed
> in one of my previous mails.

+1

> In my opinion (as I proposed), we will need
> additional interface for multi-product aware components

Why will we need such a new interface . How much will it differ ?

> (could be called
> 'IGlobalSetupParticipant').
>

afaict IWhatever ;)

[...]
>>
>> ... and thereby keep all this running in global scope .
>
> I disagree, each product (setup participants) should be upgraded from
> it's own scope. This is required as we want the translator to be running
> in the product scope to translate all tables (SQLs) correctly.
>

What I said above does not conflict with any of these . When I say in
global scope I mean : «when upgrading the global env , let's do the
same for product envs so that they will be ready to assimilate the
upgrades» rather than «upgrade the global env and let's wait until
product env will be instantiated to stop the whole site over and over
, and perform the upgrade jut for this product» . I'm not saying «do
not instantiate product envs to perform product upgrade» . I'm
basically saying «let's do them all at once (i.e. replay upgrade loop
for product envs) and , when we finish , let's make this happen in
such a way that just by creating a new product it will be ready to
work ootb ».

>
> Let's take one step back and take a look at the following use-case.
>

/me reading ... will reply asap if I have something to say about it .

-- 
Regards,

Olemis.

Mime
View raw message