bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Angel Franco Navarro <>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Fri, 22 Feb 2013 21:31:47 GMT

2013/2/22, Olemis Lang <>:
> On 2/22/13, Branko ─îibej <> wrote:
>> On 22.02.2013 11:41, Jure Zitnik wrote:
>>> On 2/22/13 3:03 AM, Branko ─îibej wrote:
> [...]
>>>> I have to say that for once I completely agree with Olemis. NULL table
>>>> column, and empty UI prefix equals "it all looks exactly like it used
>>>> to
>>>> before the migration" and it also can't collide with any existing
>>>> product names or prefixes.
>>>> Furthermore, doing it this way, if a user installs Bloodhound but
>>>> doesn't want to bother with product namespaces, everything will Just
>>>> Work.
>>> I agree with the 'Just Work' part, I don't agree with tickets in
>>> global scope.
>>> My understanding was, based on the mailing list discussions, that we
>>> don't want tickets in global scope. That is why current implementation
>>> creates the 'default' product and migrates the tickets. I think that
>>> the 'Just Work' part is more of the UI/UX issue. I think that each
>>> ticket should be linked to a product, it's up to the UI to make it
>>> easy for the user to use environments with only one product (default
>>> one). I find tickets in global scope confusing as it's not exactly
>>> clear what they relate to.
>>> I would advocate global wikis for example, as it makes more sense.
>> It's not global scope, it's default product scope which happens to have
>> no name and no prefix and no value in the related database column.
> [...]
>> Under the hood, this can be a completely different thing than the global
>> scope.
> jftr , I confirm this is what I had in mind since the beginning .
>> P.S.: By the way, do we test upgrades from Trac to BH? If not, why not?
>> :)
> We should . That's another argument against performing MP upgrade in
> EnvironmentStub.__init__ method (i.e. at the beginning of one such
> test the env would be upgraded already o.O ) . In general , testing
> upgrades will be easier after committing BEP-5 and refactoring
> MultiproductSystem procedure accordingly . AFAICR franco included some
> test cases for upgrades so it seems it all (or good part of it ;) will
> come in a single package .
> @franco : coluld you please confirm ?

Yes, BEP-5 would allow to have upgrades encapsulated per plugin
version, thus providing a better testability of specific version
upgrades as well as full from scratch upgrade scenarios.

Test cases might be written to verify specific upgrade needs as they
have been written for BEP-5 itself.

> --
> Regards,
> Olemis.

Best regards,


View raw message