bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <>
Subject BEP-0003: Database schema changes (Was: Re: [Apache Bloodhound] Proposals/BEP-0003 modified)
Date Mon, 19 Nov 2012 16:37:47 GMT
Hi all,

I updated the BEP-0003 with a (relatively short) draft proposal of 
database schema changes required to support multi-product as a first 
class citizen in Bloodhound, mostly to start the conversation on this topic.

The proposed change is based on my understanding of multiple 'product 
environments' - that all persistent entities are stored within the same 
database. If that is truly the case, all persistent per product 
instances should somehow be linked to the product. My proposition (in 
short) is:
* I suggest that the same approach is taken as with current 
bloodhound_multiproduct plugin regarding tickets
* It should be up to the plugins to handle the entity's product relation 
as needed/required
* Plugins should have the ability to query all entities regardless of 
entity's product - there are number of cases when this will be required, 
for example search plugin and ticket relations plugin


On 11/19/12 5:35 PM, Apache Bloodhound wrote:
> Page "Proposals/BEP-0003" was changed by jure
> Diff URL: <>
> Revision 17
> Changes:
> -------8<------8<------8<------8<------8<------8<------8<------8<--------
> Index: Proposals/BEP-0003
> =========================================================================
> --- Proposals/BEP-0003 (version: 16)
> +++ Proposals/BEP-0003 (version: 17)
> @@ -94,6 +94,23 @@
>   [=#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''' .
> +=== Database schema changes #database-schema-changes
> +
> +Products shall become a first-class citizen in ''Bloodhound''. To make this possible,
some changes will be required at the database schema level, especially as multiple product
environments are meant to be hosted in the same database instance.
> +
> +Currently, products are only supported in relation to tickets. Current implementation
of `bloodhound_multiproduct` plugin extends the `ticket` table by adding custom field `product`.
This field is used to reference products as defined in the `bloodhound_product` table.
> +
> +In addition to tickets, other entities should also be made ''product aware''. The product
support should be, in a similar way to tickets, extended to (at least) the following database
entities within ''Bloodhound'':
> +* versions
> +* milestones
> +* components
> +* priorities
> +* ...
> +
> +This could be accomplished using the same approach as used in relation to tickets -
by extending the database tables with the 'product' field that would reference the product
that the specified entities belong to.
> +
> +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.
> +
>   == Rationale #rationale
>   The following is a list of proposed features for multi product support in ''Bloodhound''.
Goals related to compatibility are considered in [#backwards-compatibility Backwards compatibility]
below. In each case you'll find notes explaining how candidate implementation will solve related
> -------8<------8<------8<------8<------8<------8<------8<------8<--------
> --
> Page URL: <>
> Apache 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 .

View raw message