You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Jure Zitnik <ju...@digiverse.si> on 2012/12/11 11:34:01 UTC

[BEP-0003] Database schema schanges (Was: [Apache Bloodhound] #288: Create prototype for legacy database schema proxy)

Hi,

as described in ticket #288, I produced an (experimental!) patch 
(attached to the ticket and commited on a multiproduct branch - see 
below) that provides functionalities as described in the ticket description:
- extends enum, component, version, milestone and wiki tables with 
product column
- upgrades existing database to a new schema by properly migrating 
existing configuration to a default product and multiplying the 
configuration for all products defined
- in runtime:
   - introduces BloodhoundIterableCursor that translates all SQLs 
targeted at the affected tables
   - introduces BloodhoundEnvironment skeleton that replaces trac 
Environment with product specific functionality (awareness, scope)
   - all SQLs targeted at the database are 'scoped' to a product defined 
in the environment
- the only drawback is that there is currently no UI way of changing 
product scope, at this point in time it can only be changed by modifying 
DEFAULT_PRODUCT in bloodhound.py and restarting/reloading bloodhound runtime

What this mean in practice is that through controlling product scope 
within BloodhoundEnvironment, one can (in runtime) easily change product 
scope and in turn affect all queries targeted at the resources that we 
want to be product specific. For now these resources include milestones, 
versions, components, enums (resolutions, priorities, ticket types).

Please test the patch and let me know if you run into any issues. Note 
that sqlparse (https://code.google.com/p/python-sqlparse/) is a 
prerequisite for the patch to work.

I also created a Bloodhound branch that we will use for the BEP-0003 
multiproduct development. I applied the patch from ticket #288 and we 
can go from there to implementing other BEP-0003 functionalities. I 
think that multi product branch should be separated as it affect 
basically everything from the UI to the database and will take some time 
before we have a 'release ready' solution.

Cheers,
Jure



On 12/11/12 11:00 AM, Apache Bloodhound wrote:
> #288: Create prototype for legacy database schema proxy
> ---------------------------+-----------------------------------
>    Reporter:  jure          |      Owner:  jure
>        Type:  enhancement   |     Status:  assigned
>    Priority:  major         |  Milestone:
>   Component:  multiproduct  |    Version:
> Resolution:                |   Keywords:  bep-0003 multiproduct
> ---------------------------+-----------------------------------
>
> Comment (by jure):
>
>   As described in ticket description, attached patch
>   (ticket288_r1418224_MultiproductSQLProxy.diff) is an initial
>   implementation of SQL proxy with the fore-mentioned functionality. It
>   monkey-patches trac to install BloodhoundIterableCursor and
>   BloodhoundEnvironment to capture all SQLs targeted at the database and
>   provides product aware/scope selection.
>
>   The patch does the following:
>   - introduces modified database schema by extending enum, component,
>   milestone, version and wiki tables with additional column named product
>   - database upgrade
>    -  migrates existing enums, components, milestones, versions to a default
>   product and, in addition to that, multiplies the configuration for each
>   defined product
>    - tickets w/o product are migrated to default product
>   - in runtime, the BloodhoundIterableCursor translates SQLs targeted at the
>   tables mentioned above to the scope of the product defined in
>   bloodhound.py (DEFAULT_PRODUCT). This effectively scopes all SQLs targeted
>   to translated tables to that product
>   - currently, as there is no obvious UI way of chaning product scope,
>   currently selected product scope can be changed by modifying the
>   bloodhound.py file and chaning the DEFAULT_PRODUCT...
>