On 01/07/13 15:22, Andrej Golcov wrote:
I suggest to exclude moving of tickets between products feature from
BEP-0010 and implement it as another BEP later. IMO, this adds
additional complexity to already complex problem of product-scoped
ticket numbering. We have to make sure that it will possible to
implement later (e.g. by introducing of additional history table) but
don't need to cover this in BEP-0010. I would concentrate on upgrade
and import functionality as part of feature list we want to have in
1.0 release.
I think that changing of tickets primary key to something like
id+produc_prefix (Alternative 2 in BPE-0010) is the best solution that
provides plugins backward compatibility and product-scoped numbering
as users would expect based on experience from Jira or Redmine. We
already have DB translator that emulates product scope in DB for
legacy API, so it should not be a huge change to simulate
auto-increment behaviour also.
Cheers, Andrej
Sorry if I am dragging this up when others considered this decided!
I am yet to see enough advantage in dropping the primary key at the
moment. In fact, given that I think it would probably be better to keep
the existing links to an upgraded trac environment working, I think it
is better to keep the existing primary key to support access through
/ticket/<ticket-id>. While this ability could not be extended to
imported environments that would be the case regardless.
I suppose I also don't see why maintaining the existing primary key is a
particular problem. As we already have the DB translator, this should be
able to provide the appropriate support to deal with presenting the
appropriate ticket id to support legacy plugins. How is the alternative
an improvement upon this?
Cheers,
Gary
