Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <5124B7F5.3020805@digiverse.si>
Date: Wed, 20 Feb 2013 12:48:05 +0100
From: Jure Zitnik <jure@digiverse.si>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: [BEP-0003] Custom (3rd party plugin) table upgrade to multi-product
 (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
References: <053.51bf3585855e4439e313b2cfef93bcf0@incubator.apache.org>
In-Reply-To: <053.51bf3585855e4439e313b2cfef93bcf0@incubator.apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

This is related to my previous mail on Bloodhound database upgrade to 
multi-product, this time in relation to 3rd party table upgrade.

The question is how to upgrade & migrate data from custom (3rd party 
plugin) tables. Let's assume that we're able to identify tables that 
were created by 3rd party plugins by querying SQL server schema. The 
mechanism of migration itself shouldn't be a problem as the SQL 
translator already knows how to handle those custom tables.

The question is to which product scope(s) and how the data should be 
migrated? We can't use the enabled components config as there's no way 
of linking those components to the database actual table(s).

So, I would (naively) assume that the custom tables are migrated to all 
product scope(s). The problem with that is that we don't have any way of 
knowing what Bloodhound resources are referenced from those tables. It 
should work for all resources but tickets as all the resources (those 
get multiplied during Bloodhound database upgrade) are visible from all 
scopes. The tickets are a different story as only tickets in the product 
scope will be 'visible', which was not the case prior to database 
upgrade and the custom tables might end up referencing non-existent 
(after upgrade) tickets...

Any ideas/suggestions on this one?

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.
>