On 2/28/13, Andrej Golcov <[email protected]> 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. -1 > http://host/env/products/global/ticket/1 for global env The TracLinks expression for this will be product:global:ticket:1 . The one for global env will be global:ticket:1 and will be expanded to http://host/env/ticket/1 . That's exactly what disambiguation is all about ;) > http://host/env/products/prod1/ticket/2 for prod1 env > jftr product:prod1:ticket:2 > 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 > IMO it should be '' i.e. empty string , otherwise NULL . IMO we better use '' because SQL checks for NULL values will required product IS NULL predicate as opposite to WHERE product = '' . Choosing the second will allow us to provide an uniform treatment to both global and product data at SQL translation time . -- Regards, Olemis.
