bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <>
Subject [BEP-0003] Component database schema install/upgrade
Date Thu, 21 Feb 2013 12:54:41 GMT
This is related to #406 (Database upgrade to multiproduct) and #404 
(Populate default schema on product addition).

Some time ago decision was made to also keep the component (3rd party 
plugin) table(s) scoped to a product. This has been implemented as part 
of #288. For custom tables created by plugins, the DDL and DML 
statements are translated by pre-pending the product prefix (from the 
current product environment) to the table name(s). In effect this causes 
3rd party plugins to only get product scoped view of the database (both 
system and custom tables) = separate table(s) for each product.

What I'd like to discuss is how to handle product additions and database 

My suggestions would be the following:

Product addition, from the component (IEnvironmentSetupParticipant) 
view, should be handled as new environment creation. This means that 
upon product addition, the 
IEnvironmentSetupParticipant.environment_created should be invoked for 
all components that implement that interface in the context of the newly 
created product environment. As this would provide product scoped 
interface to the database, the components would be able to properly 
create tables, insert data, etc. in the proper product scope. Also, they 
would get properly scoped references to product resources residing in 
system tables.

Database upgrades 
(IEnvironmentSetupParticipant.environment_needs_upgrade and 
IEnvironmentSetupParticipan.upgrade_environment) that are handled by 
trac.trac.env.Environment class, should be handled in a similar way that 
is handled now, but for each defined product. This would mean that both 
methods (upgrade required detection & actual upgrade) would need to 
invoke aforementioned interface methods for components implementing the 
IEnvironmentSetupParticipant for all existing products at the time of 

As a side effect of the above, the 'system' table (where the components 
store their database version) will also need to be made product aware.

For components that are multi-product aware (Bloodhound multi-product 
plugin for example) I would suggest introducing a new interface based on 
IEnvironmentSetupParticipant (calles IGlobalSetupParticipant for 
example). This interface would get invoked in the same way as the 
IEnvironmentSetupParticipant is invoked now - that is once per 
environment creation and once during upgrade. It would always get 
invoked within global environment/scope. If required, we might add 
additional methods for product addition/archival/migration notifications 
at a later stage.

Any comments/suggestions on this? :)


View raw message