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. 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.
The fact that the upgrade to multiproduct makes the product-scoped-id
for tickets in the default product the same as the ticket-ids is just an
incidental consequence of our decision to maintain stable ticket URLs,
that's all. And, I don't really care if tickets in other than the
default product cannot be accessed through the shortened URLs --
althrough I submit that a "default" product only makes sense in the
context of the upgrade, and apart from that makes no sense at all.
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
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
The second URL construction alternative would expose the ticket-id
primary key in all URLs, allowing tickets in any product to be accesses
through the shortened URL. The first alternative completely hides that
primary key from the UI and URL space, but maintains the concept of a
"default" product indefinitely.
There is a third variant, a modification of variant 1, that allows the
/ticket/<ticket-id> alias only for those tickets that existed during the
schema upgrade. IMO that would even be the best alternative because it
would not maintain the fiction that some default product is special
other than during the upgrade.
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.
(I'd even go as far as to say that Trac's exposing a datbase primary key
as an application key is bad design, but let's leave that discussion for
some other time. Suffice it to say that we have the perfect opportunity
to fix that.)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. [email protected]
