incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Fri, 22 Feb 2013 12:36:46 GMT
On 22.02.2013 11:41, Jure Zitnik wrote:
> On 2/22/13 3:03 AM, Branko Čibej wrote:
>> On 21.02.2013 18:05, Olemis Lang wrote:
>>> On 2/21/13, Jure Zitnik <> wrote:
>>>> On 2/20/13 5:21 PM, Olemis Lang wrote:
>>>>> On 2/20/13, Andrej Golcov <> wrote:
>>> [...]
>>>>>> My suggestion is to keep things simple here: if there is already
>>>>>> product named "Default', let's assign global tickets to this
>>>>>> product.
>>>>>> There should be reason why this product was called "Default" :)
>>>>> -1 ... IMO we the prefix for the global environment should be an
>>>>> empty
>>>>> string (i.e. '') or NULL (/me slightly in favor of the former) . That
>>>>> will allow us to reserve special behavior for that prefix value (if
>>>>> needed) and will not clash with any other valid product prefix since
>>>>> it's a required field in create product web form (... admin command ,
>>>>> ...)
>>>> Just to clarify, the prefix of the 'global environment' is an empty
>>>> string (''). This will, at the moment, only be used for permissions.
>>> Yes , understood .
>>> ;)
>>>> The 'default' prefix (or 'def') is used for a product to which all the
>>>> tickets that don't have product assigned are migrated to (during the
>>>> database upgrade process). The product itself is automatically added
>>>> during the upgrade/migration process.
>>> That's kind of what I was meaning in my reply .
>>>    1. Consider ticket without product before migration to be
>>>        tickets filed against the global environment .
>>>    2. Use gobal env just like any other product env with
>>>        prefix = '' , not just permissions
>>>    3. No need to create 'default' product while on upgrade
>>> PS: In the migration process we should also replicate (i.e. in DB) or
>>> inherit product configs from a single file . I advocate for the later
>>> .
>> 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.

I propose you'll have exactly three use cases:

 1. User installs BH from scratch, starts using products immediately,
    doesn't notice the magic default product.
 2. User installs BH from scratch, eventually starts using products at
    which point they move tickets from the magic default product. They,
    at least initially, don't have to be aware of products at all.
 3. An existing Trac user upgrades to BH (Hooray when that happens!),
    they don't use products and I'm sure don't want to suddenly deal
    with some meaningless "default" prefix.

Under the hood, this can be a completely different thing than the global

-- Brane

P.S.: By the way, do we test upgrades from Trac to BH? If not, why not? :)

Branko Čibej
Director of Subversion | WANdisco |

View raw message