Page "Proposals/BEP-0003" was changed by olemis Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=25> Revision 25 Comment: [BEP-0003] Product environment and setup participants (e.g. database upgrades) Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0003 ========================================================================= --- Proposals/BEP-0003 (version: 24) +++ Proposals/BEP-0003 (version: 25) @@ -90,6 +90,9 @@ will be no way to deploy plugins for a particular product, just enable/disable those installed in the global environment. + - '''[=#product-env-system_info_providers] system_info_providers''' will enumerate + components in the global environment implementing `ISystemInfoProvider`. + - '''[=#product-env-setup_participants] setup_participants''' will always be empty. - '''TODO''' [=#product-env-idem] The following methods and options will behave exactly the same as the corresponding `parent_env`'s methods: ''get_system_info'' , ''components_section'' , '''TODO''' . @@ -167,7 +170,7 @@ Another change required is the change of the fore mentioned table keys. As it currently stands, the key used in these tables is limited to the 'name' field. As this (in the modified schema) prevents users from creating versions/milestones/... with the same name for different products, key should be extended with the 'product' field. -==== Legacy schema compatibility +==== Legacy schema compatibility #db-compatibility As changing trac database schema (by adding product column) to the required tables will brake compatibility with existing trac code/3rd party plugins, a solution is required to solve that. @@ -188,7 +191,7 @@ * queries targeted at 3rd party plugin tables are modified to prefix 3rd party plugin table names with product prefix * in addition to DML, DDL statements (CREATE TABLE/INDEX, ALTER TABLE/CONSTRAINT, DROP TABLE) are also translated -===== trac tables +===== Trac tables #sql-tx-trac Some examples: @@ -319,7 +322,7 @@ AND name=%s }}} -===== 3rd party plugin tables +===== 3rd party plugin tables #sql-tx-plugins Similar to trac tables, 3rd party plugin SQLs are translated before hitting the SQL server. The difference is that in addition to productizing the trac tables, @@ -412,7 +415,14 @@ }}} Product environments are meant to implement `trac.core.ComponentManager` API and inherit global plugins installations by design. Hence every component class will have a singleton instance for each product (besides the one for the global environment). Components are enabled/disabled via `[components]` section in configuration file. The fact that each product will have a [#config separate configuration file] also means that there will be one such section to enable/disable each class on a per product basis. -This situation is quite similar to what happens nowadays in multi-environment installations. +This situation is quite similar to what happens nowadays in multi-environment installations. The main difference will be that a component may be enabled for a given product only if it's been previously enabled for the global environment . This constraint is aimed at scoping environment setup tasks (e.g. database updgrades) in the context of the global environment. Product environments will not participate at all in this process so as to avoid some undesired side-effects . One of them is explained below . + +Let's suppose plugins may be enabled at will in both global environment and product environments. Initially environment state is steady . Component `C` is installed but it has never been enabled . It requires a database upgrade . Suddenly it's enabled for product `P1` . As a consequence environment upgrade should be applied (new tables, etc ...) . Such upgrade will only be possible if an instance of `C` announces that such changes must be carried out. However there will be no such setup participant neither in the global environment list nor any other product environment besides `P1` . Summarizing, allowing for such scattered differences may lead to + + 1. Inconsistences across products requiring different upgrades but sharing the same underlying database . + 2. Complicated administration commands and related architecture . + 3. Annoying 'needs upgrade' messages showing any time and degrading user experience . + 4. Unnecessary administration overhead . }}} @@ -739,6 +749,10 @@ - ''Sourceforce.net'' and other instances of [http://incubator.apache.org/projects/allura.html Allura] - [https://www.assembla.com/features/bug-tracking Assembla] +=== Other minor features #misc + +System information has to be consistent across product environments . + == Rejected ideas #rejected Many interesting ideas have been proposed but not all could make their way into final specification because of conceptual, practical or other reasons. Below you'll find the most relevant instances together with brief comments explaining the decision as well as links to relevant messages in [http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/ bloodhound-dev mailing list archive] . -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003> Apache Bloodhound <https://issues.apache.org/bloodhound/> The Apache Bloodhound (incubating) issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0003' page. If it was not you, please report to .
