bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Fri, 22 Feb 2013 15:34:28 GMT
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 ?



View raw message