incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Wed, 20 Feb 2013 11:37:19 GMT
I don't think this was discussed on the mailing list yet.

The question is how do we upgrade existing database(s) (pre 
multi-product) to multi-product enabled one and how to migrate existing 
data to a new schema.

Upgrade that's been implemented as part of the #288 currently does the 
following:

1. adds 'default' product
This is the product to which all tickets that don't have product set are 
migrated. As there won't be any global tickets, each ticket needs to be 
in a product, so this is where all tickets w/o product set will end up 
after the upgrade. The prefix, name and description are currently set to 
'default', 'Default' and 'Default product' respectively. Open question 
remains what happens if there's a product with the same name already 
defined in the database. Any suggestions?

2. migrates tickets w/o the product set to the 'default' product

3. copies data from enum, component, milestone, version, permission and 
wiki (all 'product enabled' tables) to temporary tables

4. drops old tables (listed in step 3) - to be replaced by product 
enabled schema in step 5

5. creates new, 'product enabled' tables (list from step 3) with added 
'product' column

6. populates product enabled tables created in step 5 with data from 
step 3 for each defined product (including default one added in step 1)
This in effect multiplies product enabled resources for each defined 
product. This is required to keep the consistency across different 
products as tickets might reference any resource from previously global 
tables.
There is one exception though, for permission table the data from the 
temporary table is also populated into the global scope (empty product 
prefix).

7. drops old (temporary) tables

After the process the database ends up with:
- upgraded schema for enum, component, milestone, version, permission 
and wiki tables
- new 'default' product
- tickets that were not assigned to the product prior to database 
upgrade are migrated to the new default product
- resources from previously global scope are multiplied for each defined 
product

Any comments/suggestions on this?

Cheers,
Jure


On 2/20/13 11:45 AM, Apache Bloodhound wrote:
> #406: Database upgrade to multiproduct
> -----------------------------------+------------------
>   Reporter:  jure                   |      Owner:  jure
>       Type:  defect                 |     Status:  new
>   Priority:  major                  |  Milestone:
> Component:  multiproduct           |    Version:
>   Keywords:  bep-0003 multiproduct  |
> -----------------------------------+------------------
>   Implement database upgrade from non multiproduct enabled database to
>   multiproduct enabled one.
>


Mime
View raw message