On 6/28/13, Gary Martin <[email protected]> wrote:
> Hi,
>
:)
>
> I have to admit that I had not considered the alternative of dropping
> the existing primary key altogether.
>
> Both schemes could probably also support a
> /env/ticket/<product-prefix><scoped-id> type url if we wished so there
> is nothing particular extra to separate the ideas on that basis.
>
> If we are also taking changes of product into account, I think I would
> prefer maintaining the existing primary key. I am not sure if this
> aspect is covered by any other proposal but I believe that we are
> expecting the ability to move tickets between products and on moving,
> any old ticket links to continue to work. This would effectively mean
> something like redirecting to the current product and will take the
> current product and ticket permissions into account. This requires that
> we maintain a list of previous references and it will also be important
> to make sure that there is no accidental reuse of a previously assigned
> <scoped-id> within a product. On the assumption that we use an extra
> table to keep track of the synonyms, then keeping the current primary
> key makes sense to me.
>
> Does anyone spot any other issues we need to worry about?
>
If I understood correctly there will be two IDs for tickets (unique
auto-incremented ID + repetitive product ID). For practical reasons it
seems to me that it'd be convenient do the following :
- Retain current `ticket` PK column name as `id` to be the
product specific ticket ID
- Change the name of auto-incremented column e.g. `uid`
or whatever other name considered more appropriate
- Do not allow moving tickets to another products
... all this in spite of keeping the transition as smooth as possible .
However the ideas mentioned above are nice to have , but IMHO hard to
achieve without a lot of changes in /trac as well as potentially
multiple incompatibilities with current core and existing plugins.
--
Regards,
Olemis.
