On 28/06/13 20:53, Matevž Bradač wrote:
Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0010>
I have to admit that I had not considered the alternative of dropping the
existing primary key altogether.
Both schemes could probably also support a
/env/ticket/<product-prefix><scoped-id> type url if we wished so there is
nothing particular extra to separate the ideas on that basis.
If we are also taking changes of product into account, I think I would prefer
maintaining the existing primary key. I am not sure if this aspect is covered by any
other proposal but I believe that we are expecting the ability to move tickets
between products and on moving, any old ticket links to continue to work. This would
effectively mean something like redirecting to the current product and will take the
current product and ticket permissions into account. This requires that we maintain a
list of previous references and it will also be important to make sure that there is
no accidental reuse of a previously assigned <scoped-id> within a product. On
the assumption that we use an extra table to keep track of the synonyms, then keeping
the current primary key makes sense to me.
Does anyone spot any other issues we need to worry about?
Thanks for the feedback. I haven't started the discussion here
yet, since there are some blanks to fill in (mainly implications),
but I think that can be done in parallel.
Oh, sorry.. I didn't realise. I hope it is better to have some
discussion to get early feedback.
I assumed that moving the tickets from one product to another
would imply creating a new ticket in the target product, while
closing the one in the source product. This would of course mean
that the new ticket gets a new ID, while the old one gets a
reference (possibly a new duplicate/refersto relation?) so that
the old links would still effectively work.
Well, that is one way of doing it, yes. One inconvenience would be the
implication that you are forced to look to a different ticket to see the
past. Taking multiple movements into account this becomes a chase
backwards through time and when you also have to worry about whether a
user viewing the current ticket has the necessary permissions to see the
older tickets, things are not really as clear cut as I would like.
Another interesting little quirk of this (though not a huge additional
problem) is that if a ticket ever returns to a product, it will be in
the product twice. With my suggestion, you would probably expect to be
going back to the previous id it had in that product.
And one further quirk that springs to mind is that this may become the
first instance of a ticket resolution that we may be forced to disallow
reopening.
I don't know how
inconvenient this would be for the users, so perhaps we should
add your suggestion as a third alternative?
Well, if my ideas are worth taking into account the I guess we should.
Obviously, even if my suggestion does turn out to be the superior, we
may well live with another solution if it is easier to implement as we
can always see it as a step to the eventual solution. We can hope that
the desire to move tickets would be relatively rare.
Cheers,
Gary
