bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject [Apache Bloodhound] Proposals/BEP-0003 modified
Date Fri, 21 Dec 2012 08:02:43 GMT
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 .

Mime
View raw message