I prefer alternative 2 as it can be achieved with minimal (no?) modifications to trac objects/sql translations. Ticket behaviour will remain the same, ticket id field will still auto increment independently of the product and /ticket/id will still only work for tickets that reside in default product.
If import code wants to insert tickets with predefined numbers, it will be able to (through SQL inserts, not API). There is a caveat though. If imported ids are larger that those already used in the table, auto increment sequences need to be manually updated to generate numbers above the largest (in postgres and sqlite, mysql auto increment should just work). If sequences are not updated, new ticket ids might collide with imported ones. Anze On Mon, Jul 8, 2013 at 6:54 PM, Olemis Lang <[email protected]> wrote: > 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.
