On 7/8/13, Gary Martin <[email protected]> wrote: > 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 > [...] > > 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>.
I interpreted your statement above as to have global ticket ID and product-specific ticket ID for a single ticket. If that's the case, IMHO it is another source of confusion to have URLs /ticket/123456789 (<=global) and /ticket/products/pid/ticket/12 . I mean : - Ticket identity is ambiguous - The user would have to remember two completely unrelated IDs Instead I'd recommend to work towards /ticket/pid-12 URLs in global scope, if that's ever wanted. I'm not against having global ID for internal use (i.e. not exposed to users at all) but *now* I'd rather question how much useful it will be in practice. > 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. The way I see it the problem is not exactly about maintaining the primary key or not (/me thinking of alternative 1 in bep:0010), but rather about making existing queries work by keeping as `id` the name of product-specific ticket ID column (be it in alt 1 or alt 2) and use it in ticket-resource DB relationships. > 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? > Alternative 3 (separate product to ticket ID mapping table) is nice to have but implies a big effort when it comes to keep the solution backwards compatible . So IMO I'd move forward by implementing alt 1 or 2 soon (Release 7 ?) , have some time to test it, etc ... and move forward with alt 3 later (Release 8 ?) to support moving tickets between products. -- Regards, Olemis.
