On 28. Jun, 2013, at 17:35, Gary Martin wrote:
> Hi,
>
> Thanks for sorting out that proposal Matevz.. a portion of the current page
> is below and my thoughts on it are listed after that.
>
> On 28/06/13 12:46, Apache Bloodhound wrote:
>> === Alternative 1: Global ID + scoped ID
>> A new, product-scoped ID would be added to the Ticket table, the global ID
>> would remain the same. The scoped ID would be unique per product, and a pair
>> of (product-prefix, scoped-id) would form a new, unique identifier for the
>> ticket.
>>
>> Tickets can thus be referenced in two ways:
>> * Using the global ID, e.g. /env/ticket/42. This would function the same as
>> before upgrade.
>> * Using the product + scoped ID, e.g. /env/ticket/product/<prefix>/10
>>
>> When upgrading a single product environment to a multiproduct Bloodhound,
>> the global IDs would equal the scoped IDs, to ease the transition. Using our
>> previous example, the ticket /env/ticket/42 would be upgraded to
>> /env/ticket/product/<prefix>/42.
>>
>>
>> **Database changes**
>>
>> Old schema
>> {{{
>> PRIMARY KEY: (ticket-id) -> ticket
>> }}}
>>
>> New schema
>> {{{
>> PRIMARY KEY: (ticket-id) -> ticket
>> UNIQUE KEY: (product-prefix, scoped-id) -> ticket
>> }}}
>>
>> Creating a new ticket would increment the ticket-id (same as before), and
>> additionally the scoped-id. In order to avoid another database table to keep
>> track of the scoped-id,
>> the scoped-id could be calculated using the SELECT MAX SQL statement.
>>
>>
>> **URL mappings**
>> {{{
>> /env/ticket/<ticket-id> -> (ticket-id) -> ticket
>> /env/products/<product-prefix>/ticket/<scoped-id> -> (product-prefix,
>> scoped-id) -> ticket
>> }}}
>>
>>
>> **Upgrade**
>>
>> Upgrading from a single product environment would retain the global IDs. The
>> scoped IDs created during upgrade would be identical their global IDs.
>>
>>
>> **Import**
>>
>> Importing a new product into existing multiproduct environment would work in
>> the following manner:
>> * Each ticket gets a new global ID
>> * The scoped IDs are retained from the imported product
>>
>> **Implications**
>>
>> {{{TBD}}}
>>
>>
>> === Alternative 2: Modification of global ID
>> In this case the global ID would lose its role as a unique database primary
>> key. Instead it would be changed to being unique only per product, and the
>> pair of (product-prefix, global-id) would become a new database primary key.
>>
>>
>> **Database changes**
>>
>> Old schema
>> {{{
>> PRIMARY KEY: (ticket-id) -> ticket
>> }}}
>>
>> New schema
>> {{{
>> PRIMARY KEY: (product-prefix, ticket-id) -> ticket
>> }}}
>>
>> **URL mappings**
>> {{{
>> /env/products/<product-prefix>/ticket/<ticket-id> -> (product-prefix,
>> ticket-id) -> ticket
>> }}}
>>
>>
>> **Upgrade**
>>
>> Upgrading from a single product environment would remove the primary key
>> from the global ID column, and add a new unique primary key for the
>> (product-prefix, ticket-id) pair.
>>
>>
>> **Import**
>>
>> Importing a new product into existing multiproduct environment would simply
>> create the (product-prefix, ticket-id) pair for each imported ticket.
>>
>> **Implications**
>>
>> {{{TBD}}}
>> (Potential technical/performance issues with index not being incremental,
>> check against supported SQL databases)
>>
>
>> Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0010>
>
> 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?
Thanks for the feedback. I haven't started the discussion here
yet, since there are some blanks to fill in (mainly implications),
but I think that can be done in parallel.
I assumed that moving the tickets from one product to another
would imply creating a new ticket in the target product, while
closing the one in the source product. This would of course mean
that the new ticket gets a new ID, while the old one gets a
reference (possibly a new duplicate/refersto relation?) so that
the old links would still effectively work. I don't know how
inconvenient this would be for the users, so perhaps we should
add your suggestion as a third alternative?
Cheers,
matevz
>
> Cheers,
> Gary
