incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: [BEP-0003] Database upgrade to multi-product (Was: Re: [Apache Bloodhound] #406: Database upgrade to multiproduct)
Date Thu, 28 Feb 2013 08:14:36 GMT
Hi Gary !
:)

I'm posting inline replies based on what I considered in the patches
I'm developing my side for #390

On 2/27/13, Gary Martin <gary.martin@wandisco.com> wrote:
> On 26/02/13 09:07, Andrej Golcov wrote:
[...]
>>
>> And wiki links will probably look like (as far as I understand
>> previous discussion on this subject):
>> #<delimiter>1 - I think we cannot use "#1" since it should be reserved
>> for relative within product links to avoid migration problems
>> #prod1<delimiter>2
>> #prod2<delimiter>3
>>
>> IMHO, it is user confusing.
>>
>
> I don't think that #prod1<delimiter>123 works for me.

+1

> Would we also
> expect to see milestone:prod1<delimiter>milestone1 as appropriate?

definitely no

[..]
> I am expecting #123 to resolve to the appropriate ticket number within
> each product which, as already pointed out, helps with migration
> problems.

+1

> I don't see why this would be a particular problem for the
> global env. #123 works equally well there when you are within global scope.
>

yes

> 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)

This is it ! I'm considering global: prefix and it will work in a
similar way to Intertrac prefixes e.g. global:ticket:333 , global:#333
, ...

>  2. Allow for a missing product within product syntax to work (e.g.
>     <delimiter>123,

-1

> <delimiter>#123,

-1

> product:#123

IMO global: is less ambiguous . Besides this form will over-complicate
for no reason the solution . At present this will generate an URL of
the form /products/%23123 which would be equivalent to a link to
product having prefix '#123' . Whether we shall allow using such
prefixes or not is another discussion ; and if not they will always be
rendered as 'missing product' links thus hinting that something went
wrong in first place .

> and product::ticket:123)

This one *might* work as it's less ambiguous and should be matched by
the TracLinks resolver . If you see some value in using these ,
please let me know so that I can add it sooner than later .

>  3. Use empty quotes to miss out the product prefix (e.g.
>     ''<delimiter>123,

-1

> ''<delimiter>#123,

> product:'':#123 and
>     product:'':ticket:123)
>

AFAICS these might not work even if it seems they should. I say so
based on similar test cases I just wrote , and it seems to me that the
TracLinks resolver will leave everything after ' chars outside of link
definition (since it is in the middle ;) . Anyway I'll add a test case
to confirm this , because the ones  mention employ " chars , so they
might be treated slightly different.

> We could also consider only allowing the longhand forms of 2 or 3 above.
> I find myself leaning towards a reserved product name

+1

Summarizing , we both are in sync Gary . Further comments are welcome
, of course . I'll consider all these forms to write test cases and
see where them all will take us .

/me working on this ... should be ready soon .

-- 
Regards,

Olemis.

Mime
View raw message