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
