incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Thu, 28 Feb 2013 11:56:44 GMT
On 28/02/13 10:54, Andrej Golcov wrote:
>> For me, the only issue is how tickets within a product will refer to tickets
>> in the global scope. There are actually a fair number of potential solutions
>> including:
>>
>> 1. Reserve a keyword to represent the global env (e.g. def, default,
>>     global, null or whatever)
> +1 to have global/default/whatever keyword as it looks less ambiguous.
> In this case it worth to have also url access with the same keyword e.g.
> http://host/env/products/global/ticket/1 for global env
> http://host/env/products/prod1/ticket/2 for prod1 env
>
> In this case, there is one thing to discuss on this subject: what
> exactly global env resources have in db after migration: NULL or
> global/default/whatever string.
> Personally, +1 to have string instead of NULL
>
> Cheers, Andrej

I am worried that I might have taken this full circle. I would stick 
with NULL as the value in the database, particularly if we consider that 
there may be existing products with whatever keyword we choose. It would 
be nice to be able to ignore clashes but it might be a bit 
irresponsible. We could consider any legacy clashing products as being 
allowed to occupy that namespace and just force the use of another means 
to disambiguate.

I quite like the suggestion from Olemis of allowing something like 
global:#123 (or whatever word we choose). So, I appear to be advocating 
one or both of

    <globalkeyword>:#123
    product::#123

referring to http://host/env/ticket/123 to be the ultimate form(s) of 
disambiguation.

Cheers,
     Gary

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message