On 6/8/13, Branko Čibej <[email protected]> wrote: > On 08.06.2013 00:46, Olemis Lang wrote: >> On 6/7/13, Olemis Lang <[email protected]> wrote: >>> On 6/7/13, Matevž Bradač <[email protected]> wrote: >>>> On 7. Jun, 2013, at 20:16, Gary Martin wrote: >> [...] >>>>> And another thing.. aren't we meant to have ticket numbers being used >>>>> sequentially within each product? Would this break anything else? >>>> The ticket id is an auto-incremented database key, so I don't think >>>> that >>>> would work. >>> Unless we change the rules a bit ;) . Beyond that separate ticket ID >>> sequences per-product should work ok >>> >> WRONG ! They won't work because ticket PK is it's ID , does not >> include product . > > You are confusing an implementation detail (the database schema) and a > user-visible feature. I never proposed to change the primary key of a > ticket, as far as the schema and Trac internals are concerned.
I know , was replying to initial comment by Gary > What I > proposed was to have two ways to refer to the same ticket: the ticketid > (which is the same as it always was), and another unique key consisting > of (product-prefix, product-scoped-id). The key spaces are ismorphic. > ... and JFTR in previous messages I just said I agree [...] > > Here's how I would have expected the various ticket IDs to be assigned: > > > Old ticket schema: > > PRIMARY: (ticked-id) -> ticket > > New ticket schema: > > PRIMARY: (ticket-id) -> ticket > UNIQUE: (product-prefix, scoped-id) -> ticket > This is a very interesting suggestion . Nevertheless *if* products may be moved back and forth from one product to the other then it seems to me that a separate table still will be needed to track ticket IDs per-product . OTOH it's possible to disallow such operation . and e.g. make individual copies per-product. <ot> BTW, have we discussed anything about binding single ticket to multiple (products / components) ? </ot> > Index mutation during multiproduct schema upgrade: > > (ticket-id) -> (ticket-id) > (default-product-prefix, ticket-id) > > Create new ticket in any product: > > ticket-id = ticket_id_sequence.next > scoped-id = scoped_id_sequence[product_id].next > > URL construction (variant 1): > > /ticket/<ticket-id> -> (default-product-prefix, ticket-id) -> ticket > /product/<prefix>/ticket/<scoped-id> -> (prefix, scoped-id) -> ticket > /ticket/<prefix>-<scoped-id> -> (prefix, scoped-id) -> ticket > > Or, alternatively (variant 2): > > /ticket/<ticket-id> -> (ticket-id) -> ticket > /product/<prefix>/ticket/<scoped-id> -> (prefix, scoped-id) -> ticket > /ticket/<prefix>-<scoped-id> -> (prefix, scoped-id) -> ticket > JFTR , like I just said before, the impact of this change goes beyond just chaging DB schema and URL paths. There's a need to patch our copy of Trac to deal with (at least) - Ticket model - Resources ... and maybe also - Authz permissions - ... more TBD [...] > > The reason I keep on yammering about this is because it's going to > really, really suck if we can't maintain some kind of ticket identity > when we import tickets from other systems, or even import trac > environments into Bloodhound product environments. Ticket numbers appear > all over the place, in mails, code comments, commit messages, IRC logs > ... it's bad enough for a tracker URL to change, and IMO quite a bit > worse if that change also changes the most unique part of the ticket > identifier. > + [...] -- Regards, Olemis.
